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Specification of a Software Architecture for Capability and 
Quality-of -Service Negotiations and Session Establishment for 
Distributed Multimedia Applications 

5 

The underlying invention generally relates to the field of 
distributed mobile computing in a mobile wireless networking 
environment with distributed multimedia applications and sys- 
tems. More specifically, it is directed to the field of qual- 

10 ity negotiation and session establishment for adaptive 

real-time streaming services running on fixed and mobile de- 
vices which support different access technologies in dynamic 
wireless Internet Protocol (IP) networks, thereby including 
research and development issues which are especially related 

15 to multimedia middleware and resource reservation, mechanisms . 

A problem that distributed systems will most likely face is 
how to cope with limited resources at the end systems and in 
the network, and unstable environment conditions. Mobile. us- 

20 ers are in fact expected to incur more frequently on the un- 
fortunate case of having their QoS Contracts being no longer 
supported by the network infrastructure, due to various rea- 
sons like wireless link quality degradations, horizontal, 
and/or vertical handovers, limited amount of mobile terminal 

25 resources, etc., which shall be referred to as „QoS viola- 
tions". By assuming proper resource overprovision in the 
backbone, it can be expected that QoS violations will most 
likely originate due to handovers or within the access net- 
work, especially in the radio part thereof. 

30 

Furthermore, mobile multimedia applications dealing with mul- 
tiple media streams of information being simultaneously ex- 
changed with a multiplicity of peers require an effective and 
efficient way of negotiating capabiliti_e^ and handling QoS 
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requirements, especially in view of the aforementioned unsta- 
ble environment conditions, 

A possible way of coping with unstable environment conditions 
5 is to enable the mobile users' applications to efficiently 
and timely react to QoS violations. Peers can in fact negoti- 
ate off-line various alternative QoS Contracts at different 
levels of abstraction, so that at the time when a connection 
is established and whenever QoS violations occur, agreements 
10 on how to most effectively adapt to the mutated conditions 
can timely be accomplished among the peers. 

BRIEF DESCRIPTION OF THE PRESENT STATE OF THE ART 

15 In the European patent application EP 01 122 366.6, the End- 
to-End Negotiation Protocol (E2ENP) has already been intro- 
duced and described in detail. As the present invention de- 
velops further the ideas described in this European patent 
application, its disclosure is hereby incorporated by refer- 

20 ence . 

The following table gives a brief overview of recently pub- 
lished articles which describe the concept of QoS and capa- 
bility negotiation protocols (in alphabetical order) : 



Abbr . 


Publication 


[Ber] 


T. Berners-Lee et al.: ^Uniform Resource Identi- 
fiers (URI) : Generic Syntax x \ Networking Working 
Group, Standards Track RFC 239 6. 


[Bosl] 


L. Bos et al.: „A Framework for End-to-End User 
Perceived Quality of Service Negotiation", IETF 
Internet Draft, work in progress, <draft-bos- 
mmusic-sdpqos-f ramework-00 . txt>. It describes a 
process for negotiating QoS with SIP and SDP be- 
tween two peers. However, it does not describe 
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Abbr. 


Publication 




any architecture for the entity using this proc- 
ess . 


[Bos2] 


L. Bos et al . : „SDPng Extensions for Quality-of- 
Service Negotiation", IETF Internet Draft, work 
in progress, <draf t-bos-mmusic-sdpng-qos- 
00.txt>. It describes a process for negotiating 
QoS with SIP and SDP between two peers. However, 
it does not describe any software architecture 
for the entity using this process. 


[BRAIN] 


^Concepts for Service Adaptation, Scalability 
and QoS Handling on Mobility-Enabled Networks", 
IST-1999-10050 BRAN Deliverable 1.2 
(http://www.ist-brain.org/) . 


[BRENTA] 


A. Kassler et al.: „BRENTA - Supporting Mobility 
and Quality of Service for Adaptable Multimedia 
Communication", in: Proceedings of the 1ST Mo- 
bile Communications Summit 2000, Galway, Ire- 
land, October 2000, pp. 403-408. 


[Caml] 


G. Camarillo, W. Marshall, J. Rosenberg: 
„Integration of Resource Management and SIP", 
IETF Internet Draft, work in progress, <draft- 
ietf-sip-manyf olks-resource-07 . txt> . It develops 
the requirements of an „Of f er/Answer Model 1 " 
based on SDP, also in the sense of reservation. 
However, it does not describe any software ar- 
chitecture for the entity performing such spe- 
cific negotiations. 


[Cam2] 


G. Camarillo et al . : ^Grouping of Media Lines in 
SDP" (IETF Internet Draft, work in progress, 
<draf t-ietf-mmusic-f id-04 . txt>) . 


[Gam] 


E. Gamma et al.: „Design Patterns - Elements of 
Reusable Object-Oriented Software", Addison- 
Wesley, Reading-Massachusetts (USA), 1994. 
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Abbr. 


Publication 


[Gu] 


X. Gu, K. Nahrstedt et al.: „An XML-based Qual- 
ity-of-Service-Enabling Language for the Web", 
Project Report of the National Science Founda- 
tion, 2001. 


[Gue] 


T. Guenkovy-Luy, A, Kassler, J. Eisl, D. Man- 
date: ^Efficient End-to-End QoS Signaling - Con- 
cepts and Features", IETF Internet Draft, work 
in progress, <draf t-guenkova-mmusic-e2enp-sdpng- 
00.txt>. 


[Klyl] 


G. Klyne: „A Syntax for Describing Media Feature 
Sets", IETF RFC 2533. 


[Kly2] 


G. Klyne: „Identif ying Composite Media Fea- 
tures", IETF RFC 2938. It describes an optimiza- 
tion for the algorithm disclosed in [Klyl] by 
introducing data handles and hashing. 


[Kutl] 


D. Kutscher et al . : ^Requirements for Session j 
Description and Capability Negotiation" (IETF 
Internet Draft, work in progress, <draft- 
kutscher-mmusic-sdpng-req-01 . txt>) . 


[Kut2] 


D. Kutscher et al . : ^Session Description and Ca- 
pability Negotiation", IETF Internet Draft, work 
in progress, <draf t-ietf-iamusic-sdpng-05 . txt> . 


[Maul ] 


D. Mandato, A. Kassler, T. Robles, G. Neureiter: 
^Concepts for Service Adaptation, Scalability 
and QoS Concepts on Mobility-Enabled Networks" 
(1ST Global Summit 2001, Barcelona, September 
2001, pp. 285-293) . This article describes the 
core concepts of the End-to-End Negotiation Pro- 
tocol (E2ENP) . A similar paper has been pre- 
sented at PIMRC 2001 in San Diego, October 2001. 


[Man2] 


D. Mandato, A. Kassler, T. Robles and G. Neure- 
iter: ^Handling End-to-End QoS in Mobile Hetero- 
geneous Networking Environments" (PIMRC 2001, 
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Abbr. 


j Publication 




San Diego, 30/9/2001 to 3/10/2001, pp. c-49 to 
C-54) 


[ReqSpec] 


„End-to-End Negotiation Protocol", 1ST-2000- 
28584/SO/WPl/PI/I/003/al, MIND Internal Contri- 
bution to WP1, Activity 1.3, Work Item 2. 


[Rosl] 


J. Rosenberg, H. Schulzrinne et al . : „SIP: Ses- 
sion Initiation Protocol", IETF Standards Track, 
Network Working Group, RFC 3261. This document 
describes the Session Initiation Protocol (SIP) , 
which is an application-layer control (signal- 
ing) protocol for creating, modifying and ter- 
minating sessions with one or more participants. 


[Ros2] 


J. Rosenberg, H. Schulzrinne: „An Offer/Answer 
Model with SDP", IETF Internet Draft, work in 
progress , <draf t-iet f-mmusic-sdp-of f er-answer- 
02.txt>. This document defines a mechanism by 
which two entities can make use of SDP to pro- 
vide a common view of a multimedia session be- 
tween them. 



[CamlJ presents a multi-phase call-setup mechanism that makes 
network QoS and security establishment a precondition to ses- 
sions initiated by the Session Initiation Protocol (SIP) and 
described by the Session Description Protocol (SDP) . Network 
resources are reserved before the session is started, thereby 
using existing network resource reservation mechanisms (e.g. 
RSVP) . 



[Klyl] presents a format to express media feature sets that 
represent media handling capabilities. In addition, an algo- 
rithm is provided that matches the feature sets. It might be 
used to determine if the capabilities of a sender and re- 
ceiver are compatible. In addition; in [Kly2] an abbreviated 
format for composite media feature sets that use a hash of 
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the feature representation to describe the composite is dis- 
closed. 

In [Ros2], a complete model for a one-to-one capabilities ne- 
5 gotiation with SDP is described. However, this model suffers 
from problems caused by the definition of mutually referred 
information and information on grouping media streams due to 
the flat hierarchy structure of the SDP. 

10 [Kutl] describes a set of requirements relevant for a frame- 
work for a session description and an end-point capability 
negotiation in multi-party multimedia conferencing scenarios. 
Depending on user preferences, system capabilities or other 
constraints, different configurations can be chosen for the 

15 conference. Thereby, the need for a negotiation process . among 
the peers is identified, but not described in order to deter- 
mine a common set of potential configurations and select one 
of the common configurations to be used for information ex- 
change . This capability negotiation is used to get a valid 

20 session- description, compatible with the end system capabili- 
ties and user preferences of the potential participants.- Dif- 
ferent negotiation policies may be used to reflect different 
conference types . They also identify the need for network re- 
source reservation coupled with session setup. Finally, a 

25 proposal is drafted for describing capabilities and providing 
the negotiation language, but not a protocol. Thereby, the 
solution proposed in [Kutl] does neither consider the nego- 
tiation protocol for determining a common set of QoS configu- 
ration nor integrate local, peer and network resource reser- 

30 vation. 

The most recent version of this IETF draft, in the following 
referred to as [Kut2], provides a detailed XML Schema speci- 
fication and a prototype of the Audio Codec and Real-Time 
35 Protocol (RTP) Profiles. 
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In [Bosl], an end-to-end user-perceived QoS negotiation is 
described, with the presumption that some middleware and 
services may strongly be involved in the final decision about 

5 the negotiated QoS-inf ormation of the end peers. The decision 
as described may be taken over some standard ^contract 
types'". Although it is mentioned that the signaling and the 
data path may go different ways through the network, it is 
suggested that some middleware on the way of the negotiation 

10 path may influence the negotiation though in general having 
nothing to do with the data paths. In case this protocol 
model is deployed, the network is not transparent. The nego- 
tiation process according to [Bosl] is performed at one shot 
interleaving also with some non-QoS information (e.g. secu- 

15 rity, network admittance, etc.) without considering protocol 
modularity and information consistency with respect to QoS. 
With the model of [Bosl], it is only possible to use a push 
mode for the negotiation, which may be restrictive for some 
applications and services , The adaptation paths are only de- 

20 grading and fixed. 

In the articles [Manl], [Man2] , and [Cam2], the possibility 
of grouping media streams is discussed. However, the authors 
do not consider criteria for the grouping, the possibility of 

25 recursive group building (a group of many groups) , and the 

treatment of real, pseudo-real and non-real-time information 
media streams that also may be grouped. Besides, [Manl] and 
[Man2] define negotiation steps that may or may not run at 
one shot but not during independent negotiation phases. For 

30 this reason, they do not meet the requirements for the con- 
sistency of the negotiated' QoS information during a negotia- 
tion phase and after it. Thereby, in [Manl] the core concepts 
of the E2ENP are disclosed. The treatment of colliding „Econ- 
omy Principle" applications is also not considered. Moreover, 

35 [Manl] and [Man2] describe the possibility of setting and 
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managing adaptation paths for the QoS adaptation, which is 
controlled by a third party component - the QoS Broker, How- 
ever, the authors do not consider any possibility for the end 
parties to perform and control the negotiations on their own. 

5 

PROBLEMS TO BE SOLVED BY THE INVENTION 

Nowadays, adaptive applications and/or middleware (e.g. QoS 
Brokers) do not comprise any component which is capable of 

10 handling QoS pre-negotiation, QoS negotiation and/or QoS re- 
negotiation, resource reservation and/or release coordination 
offering a technology-independent Application Programming In- 
terface (API), which masks the type of signaling protocols 
used for implementing those mechanisms. Instead, adaptive 

15 multi-stream multimedia applications and/or middleware have 
directly to be coded against protocols like H.323, the Ses- 
sion Initiation Protocol (SIP) and/or the Session Description* 
Protocol (SDP, in future SDPng as described in [Kut2]). Fur-, 
thermore, said SIP- and/or SDP-based applications or middle- 

20 ware directly perform a parsing of the SDP data and have to 

infer the actions to be taken by examining changes on the SDP 
data from previously exchanged versions thereof. 

Another problem is that adaptive applications and/or middle- 
25 ware (e.g. QoS Brokers) are not able to express the informa- 
tion to be negotiated (e.g. capabilities, application-level 
QoS Contracts, network-level QoS Contracts, stream-level ad- 
aptation paths, and stream-group-level adaptation paths) in 
an interchangeable format. It is required that heterogeneous 
30 applications and/or middleware can easily agree on a refer- 
ence model, which said applications and/or said middleware 
can then use for dynamically configuring themselves to or- 
chestrate local, peer, and network resources according to the 
preferences and profiles of the respective user, policies of 
35 the respective systems and network providers in a coordinated 
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manner among a multiplicity of heterogeneous applications and 
middleware used by various peers. 

In the European patent application EP 01 122 366.6, the over- 
5 all E2ENP concept, its requirements, and a possible implemen- 
tation idea thereof is disclosed, however, without detailing 
any implementation. Any pre-negotiated information is not ac- 
complished in time. 

10 Although the current form of SDPng as described in [Kut2] is 
structured in a modular way, it does not consider E2ENP as- 
pects and can not be used in a modular way across different 
SIP messages (or other protocol messages) . Capability nego- 
tiations based on SDPng use the SDP Offerer/Answerer model 

15 described in [Ros2], in which complex multi-phase negotiation 
processes such as the one proposed in the scope of E2ENP are 
not explicitly taken into account. 

A process capable of considering user profile information as 
20 input for the overall QoS negotiation process is neither ad- 
dressed in the European patent application EP 01 122 366,6 
nor in SDPng. 

OBJECT OF THE UNDERLYING INVENTION 

25 

In view of the explanations mentioned above, it is the pri- 
mary object of the underlying invention to propose a negotia- 
tion method and a software architecture supporting capability 
and QoS negotiation and session establishment combined with 
30 resource reservation mechanisms for adaptive real-time serv- 
ices and multimedia applications. 

This object is achieved by means of the features of the inde- 
pendent claims. Advantageous features are defined in the sub- 
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ordinate claims. Further objects and advantages of the inven- 
tion are apparent in the following detailed description. 

SUMMARY OF THE UNDERLYING INVENTION 

5 

The underlying invention is basically dedicated to the con- 
cept and realization of a novel User Agent (UA) for an End- 
to-End Negotiation Protocol (E2ENP) - a software module en- 
capsulating the end-to-end signaling processes of the E2ENP 

10 as described in [ReqSpec] which can advantageously be ap- 
plied to define user profile and terminal capability informa- 
tion in such a way that hierarchical QoS Contract specifica- 
tions (e.g. compelling correlations across different sets of 
QoS Contracts for related media streams) can be enforced and 

15 used for deriving negotiable information. As a reference im- 
plementation of this concept, this invention describes a 
novel usage of the Session Initiation Protocol (SIP) stan- 
dardized by the Internet Engineering Task Force (IETF) in 
conjunction with extensions of the Session Description Proto- 

20 col - Next Generation (SDPng) specification based on the Ex- 
tensible Markup Language (XML) in order to implement End-to- 
End QoS Negotiation Protocol (E2ENP) concepts. More specif i- 
cally, the hereby proposed model extends the SDPng negotia- 
tion mechanisms by defining user profile and terminal capa- 

25 bility information which allow to enforce and use hierarchi- 
cal QoS Contract specifications. 

Thereby, said End-to-End Negotiation Protocol (E2ENP) is ap- 
plied to derive negotiable information, which enables a pre- 

30 negotiation, fast negotiation and a fast, dynamic re-negotia- 
tion of the end-to-end quality and capabilities for a tele- 
communication session, for multiple configurations of two or 
a multiplicity of end peers and/or middleware in a consis- 
tent, reliable, and incremental way by enabling the mobile 

35 applications to efficiently and timely react to QoS viola- 
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tions. Furthermore, the invention pertains to the concept and 
realization of a novel E2ENP User Agent which encapsulates 
the signaling part of E2ENP. Said E2ENP User Agent expresses 
the information to be negotiated in an interchangeable format 

5 in such a way that heterogeneous applications can easily 
agree on a reference model, which can then be used for dy- 
namically configuring Finite State Machines to orchestrate 
local, peer, and network resources according to the prefer- 
ences and profiles of the respective user in a coordinated 

10 manner. 

According to the underlying invention, the conversation of an 
interchangeable format between an internal (application- and/ 
or middleware-specific) and an external (SIP User Agent spe- 

15 cific) representation is performed by a Parser and a Factory 
implementation. These software components are also configur- 
able according to the specific needs of the underlying car- 
rier protocol agent, the E2ENP User Agent, and the respective 
application and/or middleware. In this connection, the spe- 

20 cific E2ENP User Agent session identification and the respec- 
tive application and/or middleware session identification, of. 
the applied negotiation processes and sub-processes are 
uniquely mapped to each other and cached in order to be able 
to uniquely identify pre-negotiation, negotiation and/or re- 

25 negotiation sessions. Thereby, the Parser, the Factory, and 
the Cache are coupled with the implementations of the respec- 
tive E2ENP User Agent. It should be noted that the configura- 
tion of these four software components - Parser, Factory, 
Cache, and E2ENP User Agent - and the User Agent of the ap- 

30 plied carrier protocol is an application-specific task, which 
depends on the needs of the respectively employed application 
and/or middleware component. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Further advantages and possible applications of the underly- 
ing invention result from the subordinate claims as well as 
from the .following description of the preferred embodiment of 
the invention, illustrated by the following figures and ta- . 
bles: • • 

Fig. 1 presents a block diagram showing the applied architec- 
ture for the User Agent (UA) of the End-to-End Negotia- 
tion Protocol ■ (E2ENP) according to the underlying inven- 
tion. 

Fig. 2 shows a first implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using a Java-based SIP stack 
( JSIP) , an SDPng Parser and Factory, 

Fig. 3 shows a second implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment - 
of the underlying invention using Sun' s Java Remote 
} Method Invocation (RMI), 

i 

Fig. 4 * : shows a third implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using the socked-based User 
Datagram Protocol (UDP) or Transmission Control Protocol 
(TCP) , 

Fig. 5 exhibits a UML class diagram showing the 
org: : mind: : e2enp package, 

Fig. -5 bis shows , the E2ENP Management API between the E2ENP UA Fac- 
tory and the Management Entities, 

Fig. 6 presents a document showing examples for the syntax of 
the E2ENP Universal Resource Identifier (URI) , thereby 
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using the Augmented Backus-Naur Form (ABNF) , 
Fig. 7 outlines a first message sequence chart (MSC) showing 

the pre-negotiation procedure enabled by the User Agent 
(UA) of the proposed End-to-End Negotiation Protocol 
(E2ENP) , 

Fig. 8 outlines a second message sequence chart (MSC) showing 

the session establishment with a QoS negotiation and re- 
source reservation coordination enabled by the User 
Agent (UA) of the proposed End-to-End Negotiation Proto- 
col (E2ENP) , 

Fig. 9 exhibits a UML class diagram showing the 
org: :mind: :e2enp: : Cache sub-package, 

Fig. 10 presents a diagram showing the top-level view of an Ex- 
tensible Markup Language (XML) description used for the 
End-to-End Negotiation Protocol (E2ENP) , 

Fig. 11 presents a diagram showing the XML substitution groups 
used for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 12 presents a diagram showing the XML purpose element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 13 presents a diagram showing the XML qosdef element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 14 presents a diagram showing the XML qoscfg element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 15 exhibits a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ac- 
cording to the underlying invention and the applied 
Parser and Cache, 

Fig. 17 exhibits a UML class diagram showing the general struc- 
ture of a Document Object Model (DOM) tree, 

Fig. 18 exhibits a UML class diagram showing a structural over- 
view of the Parser implementation using a visitor design 
pattern, 

Fig. 19 presents a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ac- 
cording to the underlying invention and the applied Fac- 
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tory and Cache, 

Fig. 20 presents a UML class diagram showing a structural over- 
view of the Factory implementation, 

Fig. 21 exhibits a UML class diagram showing the 
org: :mind: :sip: :sipApi package, 

Fig. 22 exhibits a UML class diagram showing the 

org: rmind: :sip: :sipApi: ruserAgent package, 

Fig. 23 exhibits a UML class diagram showing the 

org: rmind: : sip: :sipApi: : registrar package, 

Fig. 24 exhibits a UML class diagram showing the 

org: :mind: :sip: :sipApi: :management package, 

Fig. 25 exhibits a UML class diagram showing the 
org: :mind: :sip: :sipApi: :time package, 

Fig. 2 6 exhibits a UML message sequence chart (MSC) showing the 
configuration of the Service Provider and the binding of 
the Service User with said Service Provider, 

Fig. 27 exhibits a UML message sequence chart (MSC) showing the 
connection establishment between the User Agents of a 
client and a server, 

Fig. 28 exhibits a UML message sequence chart (MSC) showing the 
OPTIONS method used for the End-to-End Negotiation Pro- 
tocol (E2ENP) , 

Fig. 29 exhibits a UML message sequence chart (MSC) showing the 
connection release between the User Agents of a client 
and a server, 

Fig. 30 shows a first state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the root state,, 

Fig. 31 shows a second state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the NegOfferer sub-state, 

Fig. 32 shows a third state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the NegAnswerer sub-state, 

Fig. 33 shows a fourth state transition diagram for a nested Fi- 
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nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the ReNegOfferer sub-state, 

Fig. 34 shows a fifth state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the ReNegAnswerer sub-state, 

Fig. 35 shows a sixth state transition diagram for the „_Resv- 
Mtx" Finite State Machine (FSM) for allowing multiple 
requests to seize the mutex in a coordinated manner, 
based on their priority. 

Fig. 36 shows a seventh state transition diagram for a nested 
Finite State Machine (FSM) showing the mutex-related 
procedures executed in the WaitForCoordDone sub-state, 

Fig. 37 exhibits a UML message sequence chart (MSC) showing the 
pre-negotiation procedure needed for the correlation of 
the Application Programming Interface (API) of the E2ENP 
User Agent (E2ENP UA) and the generic Application Pro- 
gramming Interface (API) of the SIP User Agent (SIP UA) , 
thereby using the above-mentioned Finite State Machine 
(FSM) of the E2ENP User Agent (E2ENP UA) , 

Fig. 38 exhibits a UML message sequence chart (MSC) showing the 
session establishment with the QoS negotiation procedure 
and the resource reservation coordination needed for the 
correlation of the Application Programming Interface 
(API) of the E2ENP User Agent (E2ENP UA) and the generic 
Application Programming Interface (API) of the SIP User 
Agent (SIP UA) , thereby using the above-mentioned Finite 
State Machine (FSM) of the E2ENP User Agent (E2ENP UA) , 

Tab. 1 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 2 shows a list of primitives to be implemented by the 

Service User, based on a Java implementation of the Ap- 
plication Programming Interface (API) applied to the 
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User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 3 shows a list of primitives to be implemented by the 

Service User acting as an Offerer, based on a Java im- 
plementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 4 shows a list of primitives to be implemented by the 

Service User acting as an Answerer, based on a Java im- 
plementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab, 5 shows the methods provided by the Application Program- 
ming Interface (API) of the first Cache level, 

Tab. 6 shows the methods provided by the Application Program- 
ming Interface (API) of the second Cache level, 

Tab. 7 shows a list of primitives which have to be implemented 
by the Application Programming Interface (API) of the 
Parser, 

Tab. 8 shows a list of primitives which have to be implemented 
for generating a specific Parser instance, 

Tab. 9 shows a list of primitives which have to be implemented 
by the Application Programming Interface (API) of the 
Factory, 

Tab. 10 shows a list of primitives which have to be implemented 
for generating a specific Factory instance, 

Tab. 11 shows the methods provided by the well-known Factory- 
Factory class E2ENPContentHandlerFactory, 

Tab. 12 shows a list of primitives implemented by the Service 

Provider of the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) , based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) , 

Tab. 13 shows a list of client-side-specific primitives imple- 
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mented by the Service User, based on a Java implementa- 
tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 14 shows a list of server-side-specific primitives imple- 
mented by the Service User, based on a Java implementa- 
tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 15 shows a list of both client-side- and server-side- 
specific primitives implemented by the Service User, 
based on a Java implementation of the generic Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 16 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the generic 
Application Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 17 shows a list of primitives implemented by the Service 

User, based on a Java implementation of the generic Ap- 
plication Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 18 is a state transition table showing a survey of the ap- 
plied exception events, and 

Tab. 19 shows the applied timers applied to the End-to-End Nego- 
tiation Protocol (E2ENP) according to the underlying in- 
vention. 
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DETAILED DESCRIPTION OF THE UNDERLYING INVENTION 

According to one embodiment of the underlying invention, an 
5 E2ENP UA 128 supports the following platforms: Win32 and 
Linux. Quality, robustness, maintainability, extensibility, 
flexibility and efficiency are the challenges to the archi- 
tecture and its solutions. 

10 - Quality includes testability and verification of the system 
already during development . Robustness is the ability of 
the system to stay stable and available also in error 
situations. Both aims directly affect the availability and 
acceptance of the system. 

15 

- Maintainability and extensibility include all costs of the 
system in later phases (concerning both error correction ■' 
and extensions) . These costs must be minimized. 

20 - Flexibility also addresses the point that changes should be 
applied as cost-effective as possible. 

- Efficiency addresses minimization of resource usage (con- 
cerning memory and processor) . 

25 

For the architecture, the following basic conceptual and 
technical requirements can be derived: 

♦ definition of design components with well chosen and de- 
30 fined responsibility and features; 

♦ small dependencies between design components (loose cou- 
pling) , so that changes have only a limited effect; 

♦ minimum resource consumption, especially concerning the 
applied Random Access Memories (RAMs) ; 
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♦ a strict separation between interface and implementation 
(a change of the implementation shall not affect the in- 
terface) ; 

♦ definition of restrictions, if this simplifies the reali- 
5 zation concept - however, restrictions and their effects 

must be negotiated with the stakeholders. 

The E2ENP UA 128 depicted in Fig. 1 is designed as a software 
component which communicates with the environment through the 
10 following five APIs : 

• E2ENP Management API 101a (IF1) : This API represents the 
interface between the E2ENP UA 128 and any entities 102 
managing it, in the sense of configuration, monitoring, and • 

15 control. 

• E2ENP UA API 101b (IF2): This API represents the interface 
between the E2ENP UA 128 and any application 130 or middle- 
ware using the services offered by said E2ENP UA 128. The 

20 information exchanged through this API can be mo.deled as an 
object structure or as an XML-based document, to be accord- 
ingly interpreted by applications 130 or middleware 130 
placed on top of the E2ENP UA 128. 

25 • SIP UA Generic API 101c (IF3) : This API represents the in- 
terface between the E2ENP UA 128 and the session-layer pro- 
tocol used for implementing the E2ENP-specif ication. The 
name of this API clearly indicates that the Session Initia- 
tion Protocol (SIP) described in [Rosl] is used as a refer- 

30 ence session-layer protocol. However, with minor modifica- 
tions, this API can easily be generalized in a future de- 
sign review, so as to remove the E2E3STP UA dependency on the 
SIP. Nevertheless, by using this design it would be possi- 
ble to have a complete Java Remote Method Invocation (RMI) 

35 implementation of the SIP UA Generic API 101c (IF3) . 
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• Parser API lOld (IF4) : This API represents the interface 
between the E2ENP UA 128 and any Parser implementation 112 
used for decoding the E2ENP session description* 

5 

• Factory API lOle (IF5) : This API represents the interface 
between the E2ENP UA 128 and any Factory tool 114 used for 
encoding the E2ENP session description, 

10 Internally, the E2ENP UA 128 is composed of different Finite 
State Machines 106 (FSMs) handling the coordination of the 
procedures associated with the aforementioned interfaces, and 
their interrelations. More specifically, the E2ENP UA 128 
should feature a client FSM 106 and a server FSM 106 for in- 

15 dependently and simultaneously handling, respectively, the 
initiation of an E2ENP (pre-) negotiation and/or session es- 
tablishment, and the response to such procedures. This means '■ 
mapping primitives of the interface 101b (IF2) to primitives \ 
of the interface 101c (IF3) , and vice versa. The mapping of 

20 the primitives concerns both object and object identifiers 

mapping. The mapped objects and the identifiers are stored in 
a respective Cache 104 at the E2ENP UA 128 and/or at the ap- 
plication 130 above IF2. 

25 During this mapping process, the E2ENP UA FSMs 106 should 
also be able to access the interfaces lOld (IF4) and lOle 
(IF5) for handling, respectively, E2ENP session description 
decoding and encoding. 

30 The Parser and Factory implementations 112 and 114, respec- 
tively, though essential entities for implementing the E2ENP 
concept, are designed as- separated software components, inso- 
far as they can be implemented in various ways (based on SDP, 
SDPng, SDPng dialects, or any other session description lan- 

35 guages of choice) . 
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In the following subsection, the basic problem domains of the 
system shall be described and how they are solved within the 
E2ENP UA 128. Each problem domain is discussed individually 
5 and across the system. It refers to other problem domains if 
there is any interference with them or if a part of the prob- 
lem domain is discussed more detailed in an extra section. 

The E2ENP UA 12 8 is designed according to the object-oriented 
10 paradigm, and a Java-based prototype based on such design is 
hereby described. It allows using various types of XML pars- 
ing tools (through IF4) and various session level protocols 
(through IF3) to transport E2ENP primitives. The hereby- 
described prototype based on the aforementioned E2ENP UA de- 
15 sign uses SIP as described in [Rosl] as session-layer proto- 
cols. Various SIP implementations are supported by the E2ENP 
UA design, thanks to the abstract nature of IF3 . 

In the scope of the underlying invention, both the E2ENP UA 
20 FSM 106 and the SIP UA Generic API (IF3) are explicitly de- 
signed to support SIP. It is foreseen that in a future design 
review these dependencies will be removed by making IF3 even 
more abstract. The E2ENP UA 12 8 will also be able to simulta- 
neously support multiple users of multiple applications 130 
25 using multiple instances of the E2ENP UA services. 

The E2ENP UA 128 supports three types of object categories: 
identifiers (IDs), description objects (object graphs or a 
formal description of an object graph, like XML) and event 
30 objects. These categories correspond to the objects passed to 
the agent through IF2, IF3, IF4, and IF5 in both directions. 



35 



- The IDs are needed to uniguely identify the session de- 
scription objects. There are two types of identifiers, 
which are also objects: 
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• E2ENP internal object IDs, corresponding to the objects 
processed within the E2ENP UA FSMs 106, 

• application IDs pointing also at the respective E2ENP UA 
5 FSM 106 objects, which are used by an application 130 to 

steer negotiation events. 

- The session description objects are either object graphs 
used by the E2ENP UA FSM processing or external descrip- 

10 tions used by the Parser implementation 112, the Factory 
implementation 114, and the E2ENP UA 128 by a negotiation 
process. All these session description objects can persis- 
tently be saved by the application 130 (above IF2) using 
them. The management (leasing descriptions, refreshing of 

15 leased descriptions, etc.) of the saved objects is an ap- 
plication-specific task. 

- The event objects correspond to application negotiation 
events, which affect the E2ENP UA FSM 10 6 functionality by 

20 triggering adaptation sequences. 

The IDs, the E2ENP UA FSM object graphs and the event objects 
are Java objects. The external protocol representations can 
be SDP, SDPng, SDPng dialects, or any other session descrip- 

25 tion language objects of choice. The implementation of the 
Java objects passed through interface IF2 depend on the in- 
terface definition of IF2. The objects passed through the in- 
terfaces IF4 and IF5 are either E2ENP UA FSM 10 6 object rep- 
resentations or external protocol representations. The ob- 

30 jects passed through IF3 are external protocol representa- 
tions. All the external representations of the session de- 
scription objects passed through IF3, IF4 and IF5 should im- 
plement java.io.Serializable in order to be compatible with 
the SIP Surrogate RMI implementation. 
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The internal representations of the session description ob- 
jects passed over the IF2, IF3, IF4 and IF5 shall be typed as 
java. lang. Object and should be cast into the expected type by 
5 the E2ENP UA 128, the Parser 112, and the Factory 114. This 
requirement is necessary to keep the SIP UA 110 and the im- 
plementations of the Parser 112 and the Factory 114 modular 
by leveraging generic APIs, 

10 The following section contains a brief survey of the applied 
implementations of the Parser 112 and the Factory 114. 

Since the negotiation process involves at least two entities 
interconnected by a network, it is necessary to provide map- 

15 ping functionality from system-internal representation to a 
transport representation over the network and back. The 
mechanisms that provide this mapping are called Parser API 
lOld (in the following referred to just as Parser 112) and 
Factory API lOle (referred to as Factory 114), where the 

20 Parser 112 takes an object encoded in network representation 
as input and generates a system-internal representation of 
said object. In contrast, the Factory 114 generates a network 
representation for a given system- internal representation. 

25 The need for said Parser API lOld, said Factory API lOle and 
the functionality defined by them arises from the facts that 
the system-internal representation may not be appropriate for 
a transport representation that can be sent over networks and 
the transport representation may not be adequate for a sys- 

30 tem-internal representation. 

Additionally, introducing these components into the system 
decouples the higher application layer from the lower trans- 
port-oriented layers. As a consequence, the actually used 
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transport protocol is of no concern to the upper application 
layers and should ideally be pluggable. 

The use of the Extensible Markup Language (XML) as transport 
5 syntax is motivated by the widespread adoption of XML as an 
industry standard, and it also allows for the incorporation 
of external features (SDPng libraries and profiles) and pro- 
vides compatibility to related work (SDPng schema) . Another 
feature of XML is its simple extensibility. 

10 

As described above, the use of different carrier protocols 
requires that the Parser 112 and the Factory 114 are config- 
urable by the same means as the protocol, which means that in 
case the protocol is configurable at runtime, said Parser 112 
15 and said Factory 114 might also have to be changed while the 
system is running. This implies the specification of an ab- 
stract interface, since the actual implementations depend on 
the specific underlying carrier protocols - 

20 Concrete Factory 114 implementations for different carrier 

protocols will produce different results. For example, an RMI 
factory may just be a dummy implementation. It is thus possi- 
ble to transfer Java objects, e.g. the objects- „as is", di- 
rectly over a network connection by simply using Java Remote 

25 Method Invocation (RMI) . 

If SIP is used as a carrier protocol, however, an external 
representation (more specifically a protocol data unit or 
PDU) to be sent over the network has to be generated. Possi- 
30 bilities include but are not limited to some proprietary text 
format similar to SDP, for example, or a more structured ap- 
proach using XML, as e.g. SDPng does. 

.The API- definitions for the Parser API 101d and the Factory 
35 API lOle are un-typed in order to support loose coupling of 
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the E2ENP UA 128 and the Parser 112 as well as the Factory 
114. The transport representation as described above is im- 
plemented by just using the java . io . Serializable interface, 
which is inherently un-typed. The. system- internal representa- 
5 tion is chosen to be the represented as java . lang. Object . The 
matching between the actual implementations of the Parser 112 
and the Factory 114 and the object representation used in the 
E2ENP UA 128 have to be established by configuration. 

10 The mechanism is implemented by the following two software 
components : 

♦ Parser API lOld: Primitives of this API should accept as 
parameters any object implementing the java.io . Serializ- 

15 able interface. The result of the parsing process yields 

an object representation according to IF2, which will ab- 
stractly be typed as java. lang. Object . 

♦ Factory API lOle: Primitives of this API should accept as 
20 parameter any object representation according to IF2, 

which will be abstractly typed as java. lang. Object and 
generate a representation conforming to the 
j ava . io . Serializable interface . 

25 Additionally, in order to achieve configurability, the use of 
a ^factory design pattern" for creating Parser 112 and Fac- 
tory 114 instances is a possible solution. For this purpose, 
the factory method is parameterized with the transport proto- 
col (the distinguishing feature of different Parser 

30 112/Factory 114 implementations) . If dynamic support for dif- 
ferent carrier protocols is needed, the factory classes have 
to provide a registration procedure for new protocols . 
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In the next section, the use of SIP surrogates shall briefly 
be described. 

The applied SIP UA Generic API 101c (IF3) requires the avail- 
5 ability of a SIP UA implementation which supports such an 

API. Similarly, the Parser API lOld (IF4) and the Factory API 
lOle (F5) presume the availability of parser and factory im- 
plementations compatible with the UA implementation 110, re- 
spectively. In order to allow validating and rapidly proto- 
10 typing the E2ENP model, IF3, IF4, and IF5 have been designed 
in such a way that surrogates of real SIP UA implementations 
and of compatible Parser 112 and Factory 114 implementations 
can be used as handy alternatives for experimental purposes. 

15 By using a legacy implementation (already provided code/API 
and/or software, possibly from an external implementer) of 
the SIP UA 110 for testing and/or updating the E2ENP UA 128, 
it might be sometimes difficult to establish the connection 
between the E2ENP UA 128 and the SIP UA 110, as the interface 1 

20 provided by the legacy SIP implementation may not match di- 
rectly the interface 101c required by the E2ENP UA. In gen- 
eral, using a SIP UA 110 to provide network* connectivity for 
the E2ENP UA 12 8 is not recommended whenever testing new 
E2ENP UA 128 features, due to possible conceptual contradic- 

25 tions between the protocol agents (SIP and E2ENP) „ These con- 
tradictions may result in specification changes of the car- 
rier protocol - SIP, that is why for the tests of the E2ENP 
UA 128 the usage of a SIP emulator (which can easily adopt 
conceptual changes) is preferable. 

30 

In order to carry out a SIP emulation, SIP surrogates (e.g. 
Remote Procedure Call mechanisms, RPCs) can be employed. When 
E2ENP session description payloads have to be tested without 
necessarily using „full-blown" Parser 112 and Factory 114 im- 
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plementations, solutions coupled with the chosen SIP surro- 
gate can also be applied. 

As mentioned above, a prototype E2ENP UA 128 implementation 
5 based on the hereby-presented architectural model has been 
selected for demonstrating the E2ENP concept. Since this im- 
plementation is based on Java, an RPC-based, built-in Java 
RMI mechanism has been selected as SIP surrogate. 

10 Since RMI takes care of marshalling or demarshalling the SIP 
UA Generic API 101c (I.F3) primitives payload directly, all 
the parameters passed to the API have to implement the java. 
io . Serializable interface . 

15 In order to test E2ENP session description payloads without 
necessarily using „full-blown" Parser 112 and Factory 114 im- 
plementations (for the same reasons set forth above for the 
use of SIP surrogates) , passing such content through the IF3 
as a string might be not necessary as RMI can process ob- 

20 jects. Rather, a whole object structure representing a given 
E2ENP session description payload might be exchanged directly 
through the RMI marshalling or demarshalling mechanism. 
Therefore, the prototype E2ENP UA 12 8 implementation based on 
the hereby-presented architectural model has been designed in 

25 such a way that the IF3 primitives shall accept as parameters 
any object implementing the java.io. Serializable interface, 
and not just instances of the j ava . lang. String class. 

Said mechanism is implemented by the following software com- 
30 ponents : 

♦ SIP UA Generic API 101c: Primitives of this API shall ac- 
cept as parameters any object implementing the java.io. Se- 
rializable interface, and not just instances of the java. 
35 lang. String class. A SIP UA 110 implementation shall inter- 
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pret the passed objects as instances of the java.lang. 
String class via casting mechanism* The RMI surrogate SIP 
implementation shall directly serialize or deserialize the 
aforementioned objects „as is M . 

5 

♦ Parser API lOld: Primitives of this API shall accept as pa- 
rameters any object implementing the java . io . Serializable 
interface. 

10 ♦ Factory API lOle: Primitives of this API shall accept as 

parameters any object implementing the java . io . Serializable 
interface. 

Fig. 2 shows an implementation of the architectural model as 
15 mentioned above, based on a specific SIP UA 110 implementa- 
tion (e.g. a Java based SIP stack - JSIP) , and on Factory 114 
and Parser 112 implementations handling a modified version of 
SDPng. 

20 Fig. 3 shows an implementation of the architectural model 

mentioned above, based on an RMI SIP surrogate: In this case, 
the Factory 114b and Parser 112b implementations are simply 
dummies . 

25 The Dummy Parser Factory 118b and the Dummy Factory Factory 

120b respectively create the „Dummy Parser^ runtime instance 
112b and the „Dummy Factory" runtime instance 114b. 

Though indicated as „dummy", still, said Parser 112b and said 
30 Factory 114b could check and/or enforce that the objects used 
in the object graph are typed as „java. io .Serializable" . 

Fig. 4 shows an implementation of the architectural model 
mentioned above, using a socket-based SIP surrogate: in this 
35 case, the Factory 114c and Parser 112c implementations are 
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simply dummies. Nevertheless, one could also use the SDPng 
Parser 112a and SDPng Factory 114a to send XML based strings 
across the sockets using a proper Adapter 12 6c. The primi- 
tives are manually mapped into messages to be sent over sock- 
5 etS/ thus implementing a proprietary Remote Procedure Call 
(RPC) mechanism. 

The Dummy FactoryFactory 120c and Dummy ParserFactory 118c 
create respectively the „Dummy Parser" runtime instance 112c 
10 and the „Dummy Factory" runtime instance 114c. 

Though indicated as „dummy", still, said Parser 112c and said 
Factory 114c could check and/or enforce that the objects used 
in the object graph are typed as „java. io . Serializable" . 

15 

In the following subsections, the software components applied 
within the scope of the E2ENP UA 12 8 according to the under- 
lying invention shall briefly be described from the viewpoint 
of the component. For each software component, its require- 
20 merits, offered services and constraints are described and 
also its relations to other software components. This de- 
scription serves as the basis for the detailed design. 

Fig. 1 shows all software components and their usage rela- 
25 tions. A software component is assigned to a layer and may 

have relations to components on the same or a lower layer but 
not to software components on a higher layer. The layers do 
not have the strict meaning of encapsulating a lower layer. 

30 Accordingly, the entity using the services offered by a given 
API will be referred to as Service User, whereas the entity 
implementing the services of said API will be referred to as 
Service Provider. 
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The E2ENP UA API 101b (the aforementioned IF2) exposes the 
E2ENP UA functionality to Service Users like QoS-aware appli- 
cations 130 and/or QoS Brokers 130, according to the BRENTA 
model as described in [BRENTA] . This component realizes the 
5 specification of a generic API by defining a set of inter- 
faces and complex data types exchanged through said API. 

Thereby, said E2ENP UA API 101b allows multiple instances of 
Service Users to simultaneously access the E2ENP UA 128 func- 
10 . tionality. More specifically, the E2ENP UA 128 offers the 
following services as described in [ReqSpec] : 

1 . pre-negotiation of a multiplicity of alternative- capa- 
bilities and/or QoS Contracts (at both application and 

15 network level) ; 

2.. management of leased pre-negotiated information; . 

3. session establishment with negotiation of a multiplicity 
of alternative capabilities and/or QoS Contracts (at 
both .application and network level), potentially refer- 

20 encing pre-negotiated information; 

4. same as point 2, but with additional local, peer, and 
network resource reservation coordination; 

5. re-negotiation, similar to points 2 and 3; 

6. session release, with potential reservation release co- 
25 ordination. 

In order to expose these services, the E2ENP UA API 101b 
shall expose, respectively, the following primitives: 

30 i. pre-negotiation; 

2. leaseRenewal, which can be used for refreshing or termi- 
nating a lease; 

3. negotiation, parameterized to indicate whether resource 
reservation coordination is required. If resource reser- 

35 vation coordination is required, the E2ENP UA 128 allows 
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the Service User at the Offerer side to book the mutu- 
ally exclusive access to the resource reservation phase 
via the bookNegotiation and/or bookRenegotiation primi- 
tive; 

5 4. re-negotiation: If resource reservation coordination has 

been specified as required in the original negotiation 
phase, the E2ENP UA 128 allows the Service User at the 
Offerer side to book the mutually exclusive access to 
the resource reservation phase via the bookRenegotiation 

10 primitive; 
5. release. 



15 



The E2ENP UA API 101b has been designed based on the follow- 
ing design principles: 



1 . Primitives are classified into Request (Req) , Indication 
(Ind) , Response (Rsp) , and Confirmation (Cfm) primitives, 
according to the ISO/OSI model. Request (Req) and Response 
(Rsp) primitives are invoked by the client application 130 

20 or middleware 130 implementation (also known as Service 

User) , in order to respectively initiate or respond to a 
particular message exchange. (In some cases the message 
exchange may involve a set of different messages being ex- 
changed between peers, thanks to the abstraction offered 

25 by the given E2ENP UA implementation, whereas in other 

cases the message exchange is limited to the given message 
and its acknowledgment.) Indication (Ind) and Confirmation 
(Cfm) primitives are invoked by the E2ENP UA 128 (also 
known as Service Provider) to the registered client-side 

30 of the Service User 130, in order to respectively indicate 

the arrival of a particular message exchange or to confirm 
the conclusion of a given message exchange. (Again, in 
some cases the message exchange may involve a set of dif- 
ferent messages being exchanged between peers, thanks to 

35 the abstraction offered by the given Service Provider, 
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whereas in other cases the message exchange is limited to 
the given message and its acknowledgment.) The client-side 
of the Service User 130 must implement these primitives. 
To a request primitive generated by the peer initiating 
the given protocol message exchange, corresponds an Indi- 
cation (Ind) primitive at the target peer. To a Response 
(Rsp) primitive generated by the target peer, responding 
to the given protocol message exchange, corresponds a Con- 
firmation (Cfm) primitive at the initiating peer. 

In order to distinguish different Service Users 130, the 
E2ENP UA 128 exposes at interface 101b (IF2) one Service 
Access Point (SAP) per registered Service User 130. 
Thereby, any given Service User 130 can use more than one 
SAP at said interface 101b (IF2) in a one-to-many rela- 
tionship. 

Users can only be registered with one Service User 130 at 
a time, which means that each user will be associated with 
at most one SAP at said interface 101b (IF2) . 

In order to simultaneously and independently use different 
session layer protocols 110 (e.g. various SIP implementa- 
tions and/or RMIs), the E2ENP UA 128 exposes at interface 
101c (IF3) one SAP per registered session layer protocol. 

In order to properly associate Service Users 130 with un- 
derlying session layer protocols, the E2ENP UA 128 exposes 
at interface 101a (IF1) proper configuration mechanisms, 
which allow associating SAPs at interface 101b (IF2) with 
SAPs at interface 101c (IF3) in a one-to-one relationship. 
In this way, user using a given type of application 130 
will automatically and transparently be using the associ- 
ated session layer protocol as configured. 
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6. When configuring a SAP at interface 101c (IF3), the bind- 
ing of the E2ENP UA 128 to the session-layer protocol 110 
is done automatically. With the given SIP UA 110 Generic 
API at interface 101c (IF3) the binding in the opposite 

5 direction is done when registering a user with the E2ENP 

UA 128, and this leads to a registration of the user to 
the configured session layer protocol 110. 

7. The bidirectional binding of the Service User 130 to the 
E2ENP UA 128 is done by means of the bindReq and bindCfm 
primitives, where one of the parameters is a special iden- 
tifier, and the SAP ID (spld) uniquely identifies one of 
the configured SAPs at interface 101b (IF2) . 

8. Any given user of any given Service User 130 registers 
himself /herself on the proper Upper SAP by means of the 
regis trationReq and registrationCfm primitives, where one 
of the parameters is the aforementioned spld, which 
uniquely identifies the SAP of choice at interface 101b 
(IF2) . 

» 

9. In order to select the proper Upper SAP when locally ini- 
tiating any E2ENP session, the following primitives now 
feature a new' parameter „String user" indicating the lo- 

25 cally registered user, which uniquely identifies the SAP 

at interface 101b (IF2) said user is registered to: 

- renewLeaseReq and 

- bookNegotiationReq 

30 

10. To select the proper Upper SAP when locally initiating 
any E2ENP session, the already existing „String form" pa- 
rameter of the following primitives indicates the locally 
registered user, which uniquely identifies the SAP at in- 

35 terface 101b (IF2) said user is registered to: 
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— preNegotiationReq and 

- negotiationReq 

5 11. The instances of the application or middleware FSM 130 

and of the E2ENP UA FSM 106 are uniquely identified, re- 
spectively, by the serviceUserld and serviceProviderld. 

12. A simplified version of the ^observer design pattern" as 
described in [Gam] (implemented in Java with a derivation 
of the Java Beans event model) offers the mechanism al- 
lowing the Service User 130 to register (via a primitive 
called „Bind Request") for Indication (Ind) and/or Con- 
firmation (Cfm) primitive callbacks. 

13. In order to allow supporting E2ENP signaling extensibil- 
ity, most of the primitives allow passing a payload: To- 
day, some of these primitives are in fact not designed to 
carry payloads, but there is a chance that the E2ENP 
specification might be reviewed. Thereby, some additional 
E2ENP information piggybacking could be required. 

14. In order to allow different types of Service Users 130 
accessing the services of the E2ENP UA 110, the payloads 
are typed as the Java root class, java.lang. Object:, In 
this way, applications 130 or middleware may use either 
internal custom representations of the information to be 
exchanged via the E2ENP (e.g. an XML-based representa- 
tion) , or resort to the default information structure de- 
scribed above. 

Thereby, said E2ENP UA API 101b depends on the respective ap- 
plication 130 and/or middleware 130 using the services of 
said E2ENP UA 12 8, the applied E2ENP UA FSM 10 6, concerning 
35 the implementation of the Request (Req) and Response (Rsp) 
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primitives, and the applied Factory 114 and Parser 112: The 
chosen implementation of these components dictates the type 
of representation used 'for the information exchanged through 
this API. 

5 

The E2ENP UA API 101b has been designed with the aid of the 
object-oriented paradigm, and is thus hereby described using 
the Unified Modeling Language (UML) . The information to be 
exchanged via the E2ENP is described above. The component is 
10 composed of a basic package, the org: :mind: : e2enp as depicted 
in Fig. 5. 

To this basic package belong the following interfaces: 

15 - The Provider 504 represents the interface that an E2ENP UA • 
Service Provider implementation conforming to the herewith 
specification, shall support for implementing Request (Req) ' 
and Response (Rsp) primitives. Tab- 1 lists the primitives . 
exposed by the Provider interface 504. 

20 

- The E2ENPUserAgentListener 502 generalizes all the inter- 
faces that Service Users shall implement for intercepting 
Indication and/or Confirmation (Cfm) primitives generated 
by the E2ENP UA 128 . 

25 

Tab. 2 lists the primitives exposed by the E2ENPUserAgent- 
Listener interface 502. 

The E2ENPUserAgentListener interface 502 is specialized in 
30 the Of f ererListener interface 50 6 and the AnswererListener 
interface 508. The former is specially designed for the ap- 
plication- or middleware-initiating E2ENP procedures; the 
latter is specially designed for applications 130 or middle- 
ware 130 responding to said E2ENP procedures. 



35 
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Tab. 3 shows the primitives exposed by the Of f ererListener 
interface 506, and Tab. 4 lists the primitives exposed by the 
AnswererListener interface 508. 

5 The „to/from"-parameters passed on by the pre-negotiation and 
negotiation primitives are addresses identifying E2ENP users 
(respectively, the Offerer and the Answerer) . The E2ENP UA 
128 maps these addresses to the specific syntax used by the 
given session-layer protocol that is used for piggybacking 

10 E2ENP information: in the case of this writing, SIP. The 
E2ENP addresses shall therefore be independent of the spe- 
cific session-layer protocol, and possibly of the transport 
protocol used underneath by the E2ENP UA 128. To this extent, 
a new syntax, which has specially been designed for the 

15 E2ENP, shall herewith be proposed. 

Fig. 5 bis shows the E2ENP Management API 101a (IF1) between 
the E2ENP UA Factory 108 and the Management Entities 102, de- 
signed by means of the object-oriented paradigm. Thereby, the 

20 E2ENP Management API 101a (IF1) is composed of a basic pack- 
age, to which the following components belong: the Manager- 
Provider interface 510 and the ManagerListener interface 512. 
For the configuration of the Parser implementation 112 and 
the Factory implementation 114 via said interface IF1, the 

25 classes Conf igurationRequest 514 and ParserFactoryConf igura- 
tion 516 are used. 

Fig. 6 presents a formal description of such a Universal Re- 
source Identifier (URI) syntax by using the Augmented Backus- 

30 Naur Form (ABNF) . Thereby, said specification is similar to 
the SIP URI syntax specification described in [Rosl], but de- 
liberately does not indicate any transport protocol parame- 
ter, except for the IP address and/or port number. As an ex- 
ample of E2ENP URI, „e2enp://dave:vG$1809@acme.com" repre- 

35 sents a user named „Dave x> at the „acme^ organization, using 
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password „vG$1809". The „/ /" indication is a form of a sepa- 
rator for default user cases, when the user is not indicated 
in the address. The example „e2enp : // : xyz%45637@acme . com" 
shows a default user (which is not indicated) with a password 
„xyz%45637". 

The full or partial usage of the E2ENP address components de- 
pends on the domain model (proxying) and the address resolu- 
tion mechanisms, which are mainly part of the respectively 
applied session layer protocol (e.g. SIP). The E2ENP UA 128 
should use at least the user (default user) name and the do- 
main name to identify the communicating partners, if the ses- 
sion layer protocol is already offering some proxying and/or 
redirection mechanisms to identify the network paths. 

In the following subsections, the procedures executed by the 
E2ENP UA API 101b shall be described by means of a set of UML 
Message Sequence. Charts (MSCs) • 
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Fig. 7 depicts the simple pre-negotiation scenario in terms 
of an exchange of primitives through the E2ENP API. With re- 
spect to these primitives, specific transport protocol mes- 
sages are exchanged between the Of f ererServiceProvider 704 
and the Answerer ServiceProvider 7 06, but they are not indi- 
cated in Fig. 7 for the sake of generality. 

Fig. 8 depicts the MSC for a simple session establishment 
scenario, wherein QoS negotiation and resource reservation 
coordination processes are highlighted. In the presented sce- 
nario, for the sake of simplicity, the confirmation of re- 
source reservation completion from the Offerer side arrives 
before the same happens at the Answerer side. Likewise, this 
simple scenario assumes for the sake of simplicity that the 
resource reservation process succeeds in reserving exactly 
the amount of resource, which has originally been requested. 

The re-negotiation procedure is similar to the negotiation 
procedure, except that the names of the primitives have been 
changed as follows: 



Old Name 


New name 


bookNegotiation<type> 


bookReNegotiation<type> 


negotiation<type> 


reNegotiation<type> 


negotiationStatus<type> 


reNegotiationStatus<type> 



The Cache 104 is a database for saving different object iden- 
tifiers. In order to decouple the Service User identification 
scheme from the one specified for the E2ENP [ReqSpec] , an 
E2ENP Cache 104 is used for: 
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♦ saving and retrieving E2ENP session identifiers specified 
in [ReqSpec], 

♦ saving and retrieving the E2ENP session identifiers han- 
dled by E2ENP UA FSM 106 (serviceProviderlds) , and 

♦ saving and retrieving E2ENP UA API Service Users' session 
identifiers (serviceUserlds) . 

The Cache 104 should be searchable for different identifiers 
and following different criteria set by the E2ENP UA 128. The 
E2ENP UA 12 8 is responsible for the Cache management. 

The cached objects correspond to the identifier object cate- 
gory. The Cache 104 maintains two types of data: 

♦ Pre-cached data: The E2ENP UA pre-caches information (in- 
dexed by serviceProviderld as primary key, and service- 
Userld and E2E3STP session identifiers specified in [Req- 
Spec] as secondary keys) during the execution of a given 
E2ENP pre-negotiation or negotiation procedure. Once the 
given procedure has been successfully completed, the pre- 
cached data remains cached, so that E2ENP UA API 101b 
Service Users have reference to such data during a later 
E2ENP session as described in [ReqSpec] . 

♦ Cached data: This information can be used later, during a 
new E2ENP pre-negotiation or negotiation procedure, as a 
reference to data, which has already been (pre-) negotiated 
among the peers. For each of said E2EPN sessions, the 
Cache 104 stores the association between the given Serv- 
iceUserld and the corresponding E2ENP session identifier 
described in [ReqSpec] . Each entry in this Cache 104 is 
leased between peers and should be refreshed over time as 
described in [ReqSpec] . The Service Users 130 themselves 
are responsible for managing their own leases and (pre-) 
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negotiated information. The Cache 104 simply stores non- 
persistently the correlations among previous E2ENP ses- 
sions . 

5 The E2ENP Cache 104 is a database used for managing the nego- 
tiation object IDs. The E2ENP UA FSM 10 6 requests the Cache 
104 services. In an embodiment of this invention, the Cache 
104 is designed as a set of java.util .Hashtable objects ref- 
erencing each other. An alternative implementation based upon 
10 tupel-space technology is left for further study. 

In order to keep the E2ENP UA 128 implementation simple, the 
Cache API 103 between the Cache 104 and the E2ENP UA FSM 106 
represents a synchronous interface. 

15 

In the implemented version of the underlying invention, a 
two-stage Cache 104 is used: 

♦ Level One (LI) of said Cache 104 saves pre-cached informa- 
20 tion in form of the following tupel ( serviceProviderld, 

serviceUserld, FromSIPAddress, ToSIPAddress, E2ENPSession- 
ID) , where the FromSIPAddress and ToSIPAddress allow de- 
tecting dual seizures; the primary key is the service- 
Providerld. 

25 

♦ Level Two (L2) of said Cache 104 saves pre-cached informa- 
tion in form of the following tupel (serviceUserld, 
E2ENPSessionID) , where the primary key is the service- 
Providerld. 

30 

The two levels of the Cache 104 are implemented as two dis- 
tinct singleton objects as described in [Gam], which are ini- 
tiated and managed by the E2ENP UA 128. The Cache objects run 
within the instance of the E2ENP UA 128. Fig. 9 depicts a UML 
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Class Diagram of the org: : mind: : e2enp: : Cache sub-package that 
contains the Cache implementation. 

The singletons LevelOneCache 902 and LevelTwoCache 904 re- 
5 spectively represent the Cache level LI and the Cache level 
L2 and provide APIs for creating, searching, and releasing 
Cache entries (LevelOneEntry- 906 and LevelTwoEntry 908, re- 
spectively) . 

10 The methods provided by the API of the first and second Cache 
level (LI and L2) are depicted in Tab- 5 and Tab. 6, respec- 
tively. 

In the following subsection, an XML-based serialized .trans- 
15 port representation shall be defined by means of an XML 

schema definition. Rather than defining such a format from 
scratch, the transport representation is based upon and using 
the baseline SDPng format definition. Aside from providing 
compatibility, it is also possible to use and benefit from a 
20 third-party library and profile definitions designed for 
SDPng as described in [Kut2] . Examples include but are not 
limited to the Real-Time Protocol (RTP) as well as audio and 
video codec profiles. 

25 In order to illustrate- how the Factory API lOle and the Par- 
ser API lOld share common transport representation syntax, 
the following subsection provides one possible definition for 
such a format. The XML description of E2ENP extends and uses 
the baseline SDPng XML description format. 

30 

The XML representation for E2ENP (in the following, E2ENP 
will be used synonymously for this representation) has chosen 
to be an extension to the SDPng baseline XML definition. The 
main reason for this decision is that SDPng is expected to be 
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standardized by the IETF, which results in some major bene- 
fits : 

♦ E2ENP as an extension to SDPng will be able to benefit 

5 from external contributions to SDPng-like profile and li- 

brary definitions . There are already examples pointed out 
in the SDPng draft [Kut2], namely the audio and RTP pro- 
file. These extensions are already incorporated into, the 
specification of the E2ENP XML. 

10 

♦ Applications 130 that implement the future SDPng standard 
can more easily be enhanced to also support E2ENP, ideally 
by simply linking the E2ENP module to the application 130. 
Likewise, in heterogeneous environments, applications 130 

15 which do not support E2ENP are still able to work with the . 

SDPng-specific parts and do not break interoperability 
completely. 

The E2ENP XML representation is formally specified by an XML 
20 Schema definition as defined by the W3C. The schema defini- 
tion can roughly be separated into three parts, one contain- 
ing type definitions such as enumerations for attribute val- 
ues or the definition of common content models as complex 
types. The main part defines the top-level E2ENP sections 
25 (i.e. elements), which are also plugged into SDPng using the 
substitution group mechanism. Finally, the third part defines 
■ E2ENP-specific elements with no relation to SDPng, which are 
used to completely define the content model of the top-level 
elements . 

30 

As can be seen in Fig. 10, descType 1001 - originally defined 
in SDPng - is redefined in such a way that the E2ENP-specif ic 
header section ^purpose" 1002 appears as a legal child of the 
„desc root" element. E2ENP defines a „qosdef" section which 
35 can be used as a substitute for the „sdpng:d" element, the 
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only valid child for the „sdpng:def" 1003 section, similarly, 
„qoscfg" may be used instead of „sdpng:c", in turn the only 
valid child for the „sdpng:cfg M 1004 section. The E2ENP- 
specific element types will be described in the following. 

5 

The extensions and plug-ins to SDPng are illustrated in Fig. 
11, which shows how elements in substitution groups can be 
used to replace the head element of this group. 

10 Here, „sdpng:d" 1107 is the head element which may be substi- 
tuted by any of the members of the substitution group, that 
is, „audio:codec" 1108, „e2enp : qosdef " 1109, ,,rtp:pt" 1110, 
„rtp: transport" 1111 (which in turn again is the head element 
of a nested substitution group) and „ video : codec" 1113. Thus, 

15 by using the substitution group mechanism combined with the 
XML namespaces concept, it is possible to define modular ex- 
tensions to any XML schema definition. Additionally, the sub- 
stitution group member „rtp:udp" 1112 can further be enhanced 
in order to support the option sub-group described in [Bos2], 

20 thereby incorporating an option similar to that suggested by 
[Bos2] (not shown in Fig. 11) . 

The aforementioned „qoscfg" element 1400 is defined in the 
substitution group headed by „sdpng:c", which in turn is a 
25 valid child of the „sdpng:cfg" section. 

Using the „purpose" 1201 element depicted in Fig. 12, it is 
possible to convey additional information about the negotia- 
tion process in the external description. The general struc- 
30 ture of how the purpose element is defined is shown in Fig. 
12. 



Thereby, the header defines to which session the current mes- 
sage belongs to. It can also establish references to previous 
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sessions by means of the „use xx 1202 element, making it possi- 
ble to reference definitions from these sessions. 

Depending on what the E2ENP message is intended for, either 
5 the ^description^ 1203 or the ^mediation" 1204 element should 
be present. For example, with the aid of the ^description^ 
1203 element it is possible to state the kind of a message, 
i.e. Request (Req) or Response (Rsp) and what negotiation 
mode should be used (push, pull, push-pull) . 

10 

Fig. 13 illustrates the general structure of the „qosdef xx 
element 1300. However, there is a constraint on the usage of 
the legal child elements, depending on the value of the 
„name xx attribute of the qosdef element 1300. There are two 
15 possible values, „capabilities M and „contracts xx . Depending on 
that, the „qosdef xx section 1300 either specifies capabilities 
of a peer or, in the case of contracts, defines validated 
contracts that have been validated by entities using the 
E2ENP UA 128. 

20 

- Specifying Capabilities: In case the „name xx attribute's 
value of the „qosdef" element 1300 is ^capabilities^, the 
valid child elements are „audio : codec xx 1301, „video : codec xx 
1302, and „rtp:pt x% 1303. The respective codec elements rep- 
25 resent system capabilities of the peer in terms of audio 

- and video codecs and their configuration. By using the 
„rtp:pt xx 1303 element, it is possible to specify a desired 
RTP payload format for the given capabilities. 

30 - Specifying Contracts: In this case, the attribute value of 
the „name xx element of the qosdef element 1300 has to be 
„contracts xx . Then, the valid child elements are „policy xx 
1304, „audio xx 1305, and „video xx 1306. The „policy xx element 
has to appear exactly once. It specifies the usage for ne- 

35 gotiating the resource management policies to enforce. It 
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is possible to use a policy to optimize one or several as- 
pects of system behavior, such as optimization of memory 
usage, CPU load, network traffic or power consumption. In 
order to achieve more flexibility, these atomic aspects can 
be combined by using predicates. The elements following the 
„policy xx 1304 element can be one or many „audio" 1305, 
„ video" 1306, „data" 1308, and „control" 1307 elements. 
These elements describe the QoS Contracts for the respec- 
tive data. streams. By using the „rtp:map" 1309 element it 
is possible to define a mapping between an application 
level QoS Contract and a specific RTP payload format. 

Fig. 14 illustrates the general structure of the „qoscfg" 
element 1400. This section allows defining adaptation paths 
(AP) as well as QoS correlation and time synchronization con- 
straints at various levels of abstraction, starting from 
stream-level QoS Contracts. Each level of abstraction is 
identified by the attribute „name" of this section. Possible 
values include „stream", ^stream-group", „session", and 
application" . Thus, the definition of adaptation paths is 
possible at different levels, including stream-level adapta- 
tion paths as well as higher-level APs. The „context" 1401 
elements define possible associations of the given streams, 
thus allowing to define time-synchronization . and/or QoS cor- 
relation constraints. As such, the ,,'context" 140.1 elements 
basically describe high-level QoS Contracts. 

In the following subsection, a brief overview of the Parser 
API lOld shall be given. 

The Parser API lOld provides primitives, which can be used to 
parse a description in some transport representation and gen- 
erate an object representation according to IF2. in order to 
be able to loosely couple the E2ENP UA 128 and the Parser 
112, this object representation is abstracted in such a way 
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that it is expressed as a java . lang . Object . As already 
pointed out, the only requirement for the transport represen- 
tation is that it implements the j ava . io . Serializable inter- 
face. This can be interpreted in the sense that the transport 
5 representation is un-typed, thereby providing much flexibil- 
ity regarding what this representation can actually look 
like. 

The transport representation may contain references to exter- 
10 nal, previously defined entities. These references are left 
untouched and unresolved by the Parser 112. This issue is 
handled later in the E2ENP UA 128 or higher layer entities. 

The Parser API lOld provides one primitive for each message 
15 type to be passed. Like this, the message types are repre- 
sented implicitly and do not need to be considered in the ob- 
ject model. For each message type, the Parser 112 of f ers 'one 
primitive to parse the offer and the answer of the respective 
message type. Therefore, the general pattern depicted in Fig. 
20 15 for the Parser API lOld primitives is 

Object parseXXX (Serializable input) . 

Thereby, „XXX" denotes a placeholder for the names of primi- 
25 tives like NegOffer or PreNegAnswer, etc. (see the API defi- 
nition below for more details) . 

In addition to these general parsing methods, the Parser API 
lOld provides some specialized primitives intended to navi- 

30 gate through the content wrapped in the serialized represen- 
tation. These primitives can be used by clients to access 
specific information or data on an abstract level, independ- 
ent from the actual representation. Thus, if the representa- 
tion changes due to future protocol enhancements, the clients 

35 which use older versions of the representation are not af- 
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fected by the new changes since the information access meth- 
ods do not change. 

As the actual carrier protocol should be exchangeable, there 
is a need for providing functionality to exchange the actual 
Parser 112 implementation as well. As described above, this 
mechanism has to be the same for the Parser 112 implementa- 
tion and for the carrier protocol. 

Therefore, a ParserFactory API is defined which provides 
primitives to create an actual Parser 112 implementation in- 
stance (factory 118 depicted in Fig. 1 shows an implementa- 
tion of such a ParserFactory) . Additionally, it is possible 
to register new actual Parser 112 implementations for any 
given carrier protocol. 

The communication between the E2ENP UA 110 and the Parser 112. 
could be asynchronous, e.g. implemented by an active request ; 
interface and a passive confirmation interface. However, this 
option is not appropriate for the underlying design, because 
some gain in performance and flexibility is opposed by much 
more complicated state models for the FSMs 10 6 of the E2ENP. . 
One consequence of this decision is that the E2ENP UA 128 and 
the Parser 112 (and also the Factory 114) communicate syn- 
chronously and thus have to share a common address space, 
which in most circumstances is a reasonable assumption. 

Another consequence of this decision is that the Parser 112 
(and also the Factory 114) have to be designed as thread- 
safe, re-entrant libraries. 

The object representation, generated during the parsing and 
passed as a result back to the calling E2ENP UA 128, is de- 
scribed very abstractly by just using the java. lang. Object 
class, in order to provide loose coupling of the Parser 112 
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and the E2ENP UA 128. The actual classes implementing the 
Parser 112 for a given transport representation and a given 
object model, used in the E2ENP UA 128, have to be fitted to- 
gether by configuration. 

5 

The actual Parser and Factory implementations 112 and 114, 
respectively, have to agree on a common format for the trans- 
port representation. The definition of these formats is im- 
plementation-specific and corresponds to the actual Parser 
10 112 and Factory 114 components, even though the usage of ex- 
isting standards is encouraged and envisioned. Therefore, a 
format has been defined, which, is compatible to the baseline 
SDPng definition. 

15 The registration functionality offered by the ParserFaetory 
API can be handled in different ways. However, this is up to 
the actual ParserFaetory 112 implementation.. Some options 
what can be done with registration are: 

20 ♦ Registrations may be stored permanently to survive multi- 
ple application life cycles. 

♦ Registrations may be made public for the use of other ap- 
plications 130, which also implies permanent storage. 

♦ Registrations may only be stored in a transient way for the 
25 current application life cycle. 

Applications 130 may check if they have instantiated a match- 
ing pair of Parser 112 and Factory 114 by calling the respec- 
tive getTypeO methods of these instances and comparing the 
30 returned values for equality. The usage of a non-matching 

pair of Parser 112 and Factory 114 by an application 130 may 
result in unpredictable results and undefined or even errone- 
ous behavior. 
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In the following, the dependencies shall briefly be summa- 
rized. 

♦ IF2 Object Model: This is only an implicit dependency that 
5 actual implementations of the Parser 112 have to fulfill. 

In general, this dependency is removed by the fact that 
the Parser 112 simply creates java. lang. Object instances. 
In a specifically configured system however, which will 
actually be created, instances of the specific object 
10 model classes are used in the E2ENP UA 128. 

♦ Transport Representation: Similar to the dependency above, 
an actual Parser 112 of course needs a well-defined struc- 
ture of what it has to create. Thus, it depends on the re- 

15 spective definition of the transport representation. But 

in general, by abstractly describing the transport repre- 
sentation using java. io . Serializable, this dependency is 
removed from the design. 

20 The primitives to be implemented by the Parser API lOld can 
be taken from Tab. 7. By contrast, the primitives to be im- 
plemented for generating a specific Parser 112 are listed in 
Tab . 8 . 

25 The ParserFactory API is realized by the class E2ENPContent- 
HandlerFactory in the package org. mind. e2enp. content, also 
referred to as parser-factory implementation. It is designed 
as a singleton instance, so that all its clients can use reg- 
istrations made earlier. Currently, the singleton instance 

30 created is a default implementation, but for future releases 
it is planned to provide a configurable approach (based on 
specific system properties) to determine the class to be used 
for the singleton instance. Methods provided by the E2ENP- 
ContentHandlerFactory class are depicted in Tab. 11. 



35 
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In the following subsection, the implementation of the Parser 
112 needed for an XML-based transport representation shall 
briefly be described. Thereby, a possible Parser 112 imple- 
mentation for the XML-based transport representation is pro- 
5 posed. Fig. 17 describes the general structure of a Document 
Object Model (DOM) tree, modeled as a class DocumentTree 
1702, which aggregates one DocumentNode 1704 and can be in- 
terpreted as the document root element. Each DocumentNode 
1704 in turn aggregates between 0 and N children, thus recur- 
10 sively describing the tree structure. 

The Parser 112 for this representation can be implemented by 
using the „visitor design pattern" as described in [Gam] . The 
structural overview is given in Fig. 18. Thereby, a generic 

15 Parser 112 visitor class pVisitor 1808 is defined to use, or 
to be precise visit, 1 to N DOMNodes 1806. In order to handle 
derived DOMNodes for each specially derived DOMNode subclass, ' 
a specialized visitor is defined. (Even if the „visitor pat- 
tern" is intended for handling only subclasses, this concept 

20 can easily be extended in such a way that different element 
nodes are interpreted as categories of their own.) 

In the following, the Application Programming Interface (API) 
applied to the Factory 114 shall briefly be described. 

25 

The Factory API lOle provides primitives which can be used to 
create a transport representation for a given object repre- 
sentation according to IF2. The loose coupling of the E2ENP 
UA 128 and the Factory 114 is realized via the abstraction of 

30 the object representation (passing through the Factory inter- 
face lOle) as a java. lang. Object . As already pointed out, the 
only requirement for the transport representation is that it 
implements the java. io . Serializable interface. Therefore, the 
primitives defined by this API all return ' 

35 „java.io. Serializable" objects. 
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The object description may contain references to external, 
previously defined entities. These references are not handled 
or dereferenced by the Factory methods, they are just used. 

5 

Like the Parser 112, the Factory API lOle provides one primi- 
tive for each message type to be passed. Like this, the mes- 
sage types are represented implicitly and do not need to be 
considered in the object model. The general pattern for the 
10 Factory API primitives as depicted in Fig. 19 is: 

Serializable createXXX (Obj ect input) 

Thereby, „XXX" denotes a placeholder for the names of primi- 
15 tives like NegOffer or PreNegAnswer, etc. (see the API defi- 
nition below for more details) . 

Since the actual carrier protocol should be exchangeable, 
there is a need to provide a functionality to make the actual 

20 Factory 114 implementation exchangeable as well. As described 
above, this mechanism has to be the same for the Factory 114 
implementation and for the carrier protocol. Therefore, a 
FactoryFactory API is defined which provides primitives to 
create an actual Factory 114 implementation instance. 

25 (factory 120 in Fig. 1 shows an implementation of such a Fac- 
toryFactory.) Additionally, it is possible to register new 
actual Factory 114 implementations for any given carrier pro- 
tocol in order to illustrate how the Factory API lOle and the 
Parser API lOld share a common transport representation syn- 

30 tax . 

Communication between the E2ENP UA 128 and the Factory 114 
could be asynchronous,, e.g. implemented by an active request 
interface and a passive confirmation interface. This option 
35 is not used in the scope of the underlying invention because 
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some gain in performance and flexibility is opposed by much 
more complicated state models for the FSMs 10 6 of the E2ENP. 
One consequence of this decision is that the E2ENP UA 128 and 
the Factory 114 (also the Parser 112) communicate synchro- 
5 nously and thus have to share a common address space, which 
in most circumstances is a reasonable assumption. 

Another consequence of this decision is that the Factory 114 
(and also the Parser 112) have to be designed as thread-safe, 
10 re-entrant libraries . 

In order to provide loose coupling of the Factory 114 and the 
E2ENP UA 128, the transport representation, generated by the 
Factory 114 and passed back to the calling E2ENP UA 128 as a 

15 result, is abstractly described by using the 

java.io.Serializable class. Similarly, the java. lang. Object 
class abstractly describes the inputs of the Factory 114 
primitives. Thus, the actual classes implementing a Factory 
114 for a given transport representation and a given object 

20 model used in the E2ENP UA 128 have to be fitted together by 
configuration. 

The actual Parser 112 and Factory 114 implementations have to 
agree on a common format for the transport representation. 
25 The definition of these formats is implementation-specific 

and corresponds to the actual Parser 112 and Factory 114 com- 
ponents, even though the usage of existing standards is en- 
couraged and envisioned. Therefore, a format is proposed 
which is compatible to the baseline SDPng definition. 

30 

The registration functionality offered by the FactoryFactory 
120 can be handled in different ways. Some options for regis- 
trations include but are not limited to: 
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♦ Registrations may be stored permanently to survive multi- 
ple application life cycles - 

♦ Registrations may be made public for the use of other ap- 
plications 130, which also implies permanent storage. 

♦ Registrations may only be stored in a transient way for the 
current application life cycle. 

Applications 130 may check if they have instantiated a match- 
ing pair of Parser 112 and Factory 114 by calling the respec- 
tive getTypeO methods of these instances and comparing the 
returned values for equality. The usage of a non-matching 
pair of Parser 112 and Factory 114 by an application 130 may 
result in unpredictable results and undefined or even errone- 
ous behavior. 

In the following, the dependencies shall briefly be summa- 
rized: 

♦ IF2 Object Model: This is only an implicit dependency that 
actual implementations of the Factory 114 have to fulfill. 
In general, this dependency is removed by the fact, that 
the Factory 114 simply expects java.lang. Object instances 
as input data. In a specifically configured system, how- 
ever, which actually will be passed in to the creation 
process, instances of the specific object model classes 
are used in the E2ENP UA 128. 

♦ Transport Representation: Similar to the dependency above, 
an actual Factory 114 of course needs a well-defined 
structure of what it has to create. Thus, it depends on 
the respective definition of the transport representation. 
But in general, by abstractly describing the transport 
representation using java. io . Serializable, this dependency 
is removed from the design. 
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The primitives specified by the Factory API lOle can be taken 
from Tab* 9. Additionally, the primitives to be implemented 
for generating a specific Factory 114 are listed in Tab. 10. 

5 

The FactoryFactory API is realized by the class 
E2ENPContentHandlerFactory in the package or g. mind. e2enp . con- 
tent, also referred to as factory-factory implementation. It 
is designed as a singleton instance, so that all its clients 

10 can use registrations made earlier. Currently, the singleton 
instance created is a default implementation, but for future 
releases it is planned to provide a configurable approach 
(e.g. based on specific system properties) to determine the 
class to be used for the singleton instance. Methods provided 

15 by the E2ENPContentHandlerFactory class can be taken from 
Tab. 11. 

In the following subsection, a possible Factory 114 imple- 
mentation for the XML-based transport representation shall be 
20 presented. 

Like the Parser 112, the Factory 114 implementation uses the 
^visitor design pattern" described in [Gam] . The structure is 
illustrated by Fig. 20. 

25 

Again, a generic Factory 114 visitor class fVisitor 2002 is 
defined which visits 1 to N instances of Obj ectGraphNode 2004 
classes. For each concrete subclass of Obj ectGraphNode, a 
corresponding concrete visitor class is defined. 

30 

In the following subsection, a brief overview of the SIP User 
Agent Generic API 101c (IF3) shall be given. 

Since the SIP User Agent Generic API 101c exposes the func- 
35 tionality of a generic SIP UA 110 to the E2ENP UA 128, the 
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main object of this API is to mask the actual implementation 
of the SIP UA 110 from the E2ENP UA FSM 106. The SIP User 
Agent Generic API 101c realizes the specification of such ge- 
neric API by defining a set of interfaces and complex data 
5 types exchanged through said API . Specific SIP UA 110 imple- 
mentations will be able to expose their native (eventually 
standard) APIs by means of specific Adapters, which shall map 
the SIP API native interfaces into the SIP UA Generic API 
101c, and vice versa. 

10 

The SIP UA Generic API 101c allows multiple users to simulta- 
neously access a given SIP UA 110 implementation (via multi- 
media applications 130 or middleware 130) for simultaneously 
establishing multiple SIP sessions. 

15 

The SIP UA Generic API 101c also supports SIP Registrar im- 
plementations with the SIP signaling required by these enti- 
ties. To this extent, it should be noted that the SIP UA Ge- 
neric API 101c is not designed to allow the simultaneous sup- 

20 port of users' applications 130 and SIP Registrars on the ' 
same memory address space. With this design choice, SIP .Reg- 
istrar implementations . are thus forced to run as standalone 
server side entities, distinct from pure application 130 or 
middleware 130 entities (in the present context, the E2ENP UA 

25 FSM 106). Applications 130 and/or middleware 130 (in the pres- 
ent context, the E2ENP UA FSM 106), and SIP Registrar imple- 
mentations are examples of Service Users. A SIP UA 110 im- 
plementation exposing the SIP UA Generic API 101c represents 
the Service Provider. 

30 

The SIP UA Generic API 101c has originally been designed to 
expose an API from a specific open source SIP UA 110 imple- 
mentation, the Mitre's JSIP v. 0.8 library 

(http://jsip.sourceforge.net/), wherein API support is quite 
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poor. The SIP UA Generic API 101c has been designed based on 
the following design principles: 

1. The definition of a set of primitives identifying vari- 
ous SIP procedures abstracted at a relatively high- 
level, thereby simplifying the E2ENP UA FSM 106 design. 
Of course, the granularity of the procedures exposed by 
the current version of the- SIP UA Generic API 101c re- 
flects to a certain extent the capability of the JSIP 
implementation. Other SIP UA 110 implementations might 
offer more or less capabilities, which would require 
respectively more or less logic embedded in the corre- 
sponding aforementioned Adapters. 

2. The current version of the SIP UA Generic API 101c fo- 
cuses only on the minimal set of features required for 
prototyping and testing the E2ENP UA 128. Therefore, 
the current version of SIP UA Generic API 101c is on 
purpose neither a complete SIP API specification nor 
meant to be standardized whatsoever. 

3. Primitives are classified into Request (Req) , Indica- 
tion (Ind), Response (Rsp) , and Confirmation (Cfm) 
primitives according to the ISO/OSI model. Request 
(Req) and Response (Rsp) primitives are invoked by the 
client Service User of the IF3 101c, or by a SIP Regis- 
trar implementation in order to respectively initiate 
or respond to a particular message exchange. (In some 
cases the message exchange may involve a set of differ- 
ent messages being exchanged between peers, thanks to 
the abstraction offered by the given SIP UA 110 imple- 
mentation, whereas in other cases the message exchange 
is limited to the given message and its acknowledg- 
ment.) Indication (Ind) and Confirmation (Cfm) primi- 
tives are invoked by the Service Provider 110 to the 
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registered client-side of the Service User of the IF3 
101c in order to respectively indicate the arrival of a 
particular message or initiation of a particular mes- 
sage exchange or to confirm the conclusion of a given 
message exchange. The client-side of the Service User 
of the IF3 101c has to implement these primitives. To a 
Request (Req) primitive generated by the peer initiat- 
ing the given protocol message exchange corresponds an 
Indication (Ind) primitive at the target peer. To a Re- 
sponse (Rsp) primitive generated by the target peer, 
responding to the given protocol message exchange, cor- 
responds a Confirmation (Cfm) primitive at the initiat- 
ing peer. 

4. A simplified version of the ^observer design pattern" 
as described in [Gam] (implemented in Java with ■ a deri- 
vation of the Java Beans event model) offers the mecha- 
nism allowing the Service User to register (via a 
primitive called „Bind Request") for Indication (Ind) 
and/or Confirmation (Cfm) primitive callbacks. 

5. In order to allow supporting E2ENP piggybacking over 
SIP/ each primitive allows passing a payload, e.g. SDP, 
SDPng, or Multipurpose Internet Mail Extension (MIME) 
content. 

6. In order to allow dry- run tests of the E2ENP signaling 
logic without the support of a real SIP UA 110 imple- 
mentation and of SDP/SDPng Parsers 112 and/or Factories 
114, the primitives are designed to handle the payloads 
as generic objects (instead of plain objects represent- 
ing ASCII strings) that can be marshalled or demar- 
shalled when using Remote Procedure Call (RPC) mecha- 
nisms, like Java serialization or deserialization in 
combination with Java RMI . 
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7. Since Mitre's JSIP Version 0.8 implementation used for 
designing this SIP UA Generic API 101c lacks proper 
support of the SIP Expires header field, which is typi- 
5 cally manipulated by Service Users, an abstraction of 

this SIP header field has been created for handling any 
type of implementation of this field. This would be not 
necessary with other better SIP UA 110 implementa- 
tions, where the designer would have the choice to ei- 
10 ther change the SIP UA Generic API 101c (and therefore 

the E2ENP UA FSM 10 6 implementation) accordingly or 
provide an Adapter 12 6c mapping the Expires header 
field support of the given Service Provider (without 
changing the E2ENP UA FSM 10 6 implementation) . 

15 

Further design choices are: 

• The E2ENP negotiation model described in [ReqSpec] is a 
key aspect of the E2ENP and a piece of information in- 

2( > tended for being embedded into SDPng payload and ex- 

changed among peers on an end-to-end basis. For the sake 
of rapidly prototyping the E2ENP UA 12 8, a helper class 
named SipNegotiationModel 2216, representing the E2ENP 
negotiation model information, has provisionally been 

25 included into the SIP UA Generic API 101c. 

• Instead of uniquely identifying active sessions at ap- 
plication level by using the alphanumeric SIP Call Iden- 
tifier header field, the SIP UA Generic API 101c uses a 

30 numerical integer identifier, named connectionld. This 

choice was dictated by the following reasons: 



35 



Service users can more easily handle lists 
with numerical identifiers rather than with alpha- 
numerical ones. 
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Should the E2ENP UA 128 use other protocols 
instead of SIP in future, having generic primi- 
tives and generic session identifiers would help 
partly reusing the existing E2ENP UA FSM 106 de- 
5 sign. 

The SIP UA 110 associates an unused value of the con- 
nectionld to the SIP Call Identifier header field of an 
incoming INVITE, OPTIONS, MESSAGE, or REGISTER method. 
10 By applying the same design principle, Service Users re- 

questing the transmission of any of those methods would 
obtain the connectionld value selected by the Service 
Provider in the Confirmation (Cfm) primitive associated 
with the original Request (Req) primitive. 

15 

Unfortunately, this solution is affected by to two prob- 
lems : 

1. Without yet knowing the connectionld value as- 
20 sociated with a given Request (Req) primitive, 

Service Users can not correlate a Confirmation 
(Cfm) primitive with its corresponding Request 
(Req) primitive. 

2. Before the arrival of a Confirmation (Cfm) 

25 primitive, intermediate messages (eventually indi- 

cating failure situations) might generate addi- 
tional primitives (e.g. a Connection Status Indica- 
tion) , which would lead to the same correlation 
problem described in the previous point. 

30 

To solve these problems, the Service User must be in 
charge of selecting an unused connectionld value and 
force the SIP UA 110 associating such value with a 
proper SIP Call Identifier header field value. 



35 
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The set of connectionld values allocated by the Service 
Provider in case of incoming INVITE, OPTIONS, MESSAGE, 
or REGISTER methods and by the Service User in case of 
outgoing INVITE, OPTIONS, MESSAGE, or REGISTER methods 
should be distinct, so that the processing of incoming 
and outgoing INVITE, OPTIONS, MESSAGE, or REGISTER meth- 
ods can simultaneously take place without interference. 

However, for the sake of simplicity, the SIP UA Generic 
API 101c has been designed with a centralized management 
of connectionld values allocation, embedded into the 
Service Provider itself. Service users are yet in charge 
of allocating connectionld values for outgoing INVITE, 
OPTIONS, MESSAGE, or REGISTER methods, but the actual 
allocation is delegated to the Service Provider by in- 
voking the getConnectionld ( ) method exposed by Service 
Provider. This method can in no way be considered a 
primitive itself, since it directly returns a value (the 
selected connectionld value) : For instance, this would 
prevent implementing a loosely coupled interface, where 
primitives are exchanged between Service User and Serv- 
ice Provider via a (not RPC-like) message-based proto- 
col. In any case, Service Users and Service' Providers 
can be designed without the centralized connectionld 
value allocation management, and yet being compliant 
with the SIP UA Generic API 101c, by simply not using 
respectively implementing the getConnectionld ( ) method. 
As a special case, a connectionld can be reused in case 
of SIP re-INVITEs: in this case, a proper Boolean pa- 
rameter indicating whether this is a re-INVITE, shall be 
passed to the connectionReq primitive (see below) . 

• Some primitives of the SIP UA Generic API 101c are SIP- 
specif ic: 
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provisionalAck(Req| Ind|Rsp|Cfm) , which is used 
to implement the PRACK method, 

register (Req| Ind|Rsp|Cfm) , which is used to 
implement the REGISTER method, 
5 • options (Reql Ind|Rsp|Cfm) , which is used to im- 

plement the OPTIONS method, and 

message (Reql Ind | Rsp | Cfm), which is used to im- 
plement the MESSAGE method. 

10 These primitives will eventually be mapped to more ge- 

neric ones in a future E2ENP UA 128 design review in or- 
der to transform the SIP UA Generic API 101c into a 
E2ENP Session Level Protocol API, which will be totally 
independent of the session-layer protocol actually used. 

15 

• The current version of the SIP UA Generic API 101c de- 
sign is only partially compliant with the latest working 
(as of this writing) version of the SIP specification 
described in [Rosl] . For instance, REFER, DO, NOTIFY, 
' 20 SUBSCRIBE methods and many other features have been 

omitted since they are not essential for testing the 
E2ENP concept. The BYE and CANCEL methods are supported' 
by the same Disconnection primitive. 

25 Thereby, said E2ENP UA API 101b depends on the applied E2ENP 
UA FSM 106, concerning the implementation of the Indication 
(Ind) and Confirmation (Cfm) primitives and the Management 
component 102, which is used for configuring, controlling, 
and resetting the underlying SIP UA 110. 

30 

The SIP UA Generic API 101c has been designed using the ob- 
ject-oriented paradigm, and is thus hereby described by using 
the Unified Modeling Language (UML) ..It is composed of a ba- 
sic package, the so-called org :: mind: : sip :: sipApi as depicted 
35 in Fig. 21. To this basic package belong the classes SipEnd- 
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User 2214 and SipExpiresHandling 2112. The SipEndUser class 
2214 represents a user accessing the SIP services offered by 
the SIP UA Generic API 101c. The SipExpiresHandling class 
generalizes the functionality for manipulating the SIP Ex- 

5 pifes header field. The SipListener 2108 generalizes all the 
interfaces that Service Users shall implement for intercept- 
ing Indication (Ind) and/or Confirmation (Cfm) primitives 
generated by the SIP UA 110. The SipProvider 2110 generalizes 
all the interfaces that the Service Provider shall support 

10 for implementing Request (Req) and Response (Rsp) primitives. 

Four sub-packages complete the SIP UA Generic API 101c speci- 
fication: one, the- org: rmind: : sip: : sipApi : : time, deals with 
the SIP Expires header field abstraction, whereas the other 
15 three characterize different roles of the Service User: 



• org: : mind: : sip: : sipApi: :userAgent represents the applica- 
tion 130 / middleware 130 implementation (in the present 
context, the E2ENP UA FSM 10 6) ; 

20 • org: : mind: : sip: : sipApi : -.management represents the manage- 
ment entity 102; 

• org: :mind: : sip: : sipApi :: registrar represents the SIP Regis- 
trar implementation 2306. 



25 The org: : mind: : sip: : sipApi : :userAgent sub-package (cf. Fig. 
22) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c that the Service User of the IF3 
101c (in the present context, the E2ENP UA FSM 106) use for 
accessing the Service Provider. It consists of three major 

30 parts : 



1. Interfaces that Service Users of the IF3 101c shall im- 
plement for intercepting the Indication (Ind) and Con- 
firmation (Cfm) primitives generated by the Service 
35 Provider 110: 
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- SipUserAgentListener 2202: common to both client 
and server side; a specialization of the 

org: :mind: :sip: rsipApi: : SipListener interface 2108. 

- SipUserAgentClientListener 2206: specific for the 
client side; a specialization of the SipUserAgent- 
Listener interface 2202. 

- SipUserAgentServerListener 2204: specific for the 
server side; a specialization of the SipUserAgent- 
Listener interface 2202. 

2. Classes bundling parameters for specific primitives 
{currently only the SipConnectionReq class 2208 for the 
Connection Request (Req) primitive, the SipRegistration- 
Req class 2218 for the Registration Request (Req) primi- 
tive, and the SipRegistrationCfm class 2220 for the Reg- 
istration Confirmation (Cfm) primitive) . Instances of 
these classes are passed as parameters of the given 
primitives to the modules implementing the primitives. 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 

3. Interfaces and classes specifying the API that the 
Service Provider shall support for being compatible with 
the SIP UA Generic API 101c. The SipUser Agent Type inter- 
face 2210 specifies the set of Request (Req) and Re- 
sponse (Rsp) primitives that the underlying SIP UA 110 
implementation shall support for being compatible with 
the SIP UA Generic API 101c. The SipUserAgentType inter- 
face 2210 is a specialization of the 

org: :mind: :sip: :sipApi: :SipProvider 

interface. The SipUserAgent class 2214 wraps any given 
implementation of the aforementioned SipUserAgentType 



WO 2004/039031 



PCT/EP2003/011439 



interface 2210, by applying the ^abstract factory" and 
„singleton" design patterns as described in [Gam] . The 
^abstract factory" is defined by the SipUserAgentFactory 
interface 2212. The SipUserAgent class 2214 is designed 
5 to use a default implementation by using the deflmpl 

class attribute holding the fully qualified class name 
of the default implementation. Custom implementations of 
the aforementioned SipUserAgent Type interface 2210 can 
be created by providing specific factory classes imple- 
10 menting the aforementioned SipUserAgentFactory interface 

2212. The SipUserAgent class 2214 provides a class 
method called setUserAgent Factory () , which stores a sin- 
gleton instance of the given custom factory. 

15 Finally, this sub-package contains a class named SipNegotia- 
tionModel 2216, which represents the E2ENP negotiation model. 

The org: :mind: :sip: zsipApi: : registrar sub-package (cf . Fig. 
23) contains interfaces and classes specifying the part of 
20 the SIP UA Generic API 101c that SIP Registrar implementa- 
tions used for accessing the Service Provider. It consists of 
three major parts: 

1. Interfaces that Service Users of the IF3 101c shall im- 
25 plement for intercepting the Indication (Ind) and Con- 

firmation (Cfm) primitives generated by the Service 
Provider : 

SipRegistrarListener 2302: common to both client 
30 and server side; a specialization of the 

org: rmind: :sip: :sipApi: :SipListener 



35 



interface 2108. 
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2. Classes bundling parameters for specific primitives 
(currently only the SipRegistrationlnd class 2308 for 
the Registration Indication (Ind) primitive, and the . 
SipRegistrationRsp class 2310 for the Registration Re- 
sponse (Rsp) primitive) . Instances of these classes are 
passed as parameters of the given primitives to the mod- 
ules implementing the primitives. This solution allows 
extending and/or changing API details without disrupting 
the primitive signatures. 

3. Interfaces and classes specifying the API that the 
Service Provider 110 shall support for being compatible 
with the SIP UA Generic API 101c. The SipRegistrarType 
interface 2304 specifies the set of Request (Req) and 
Response (Rsp) primitives that the underlying SIP UA 110 
implementation shall support for being compatible with 
the SIP UA Generic API 101c. The SipRegistrarType inter- 
face 2304 is a specialization of the 

org: :mind: : sip: : sipApi : : SipProvider 

interface 2110. The SipRegistrar class 2306 wraps any 
given implementation of the aforementioned SipRegistrar- 
Type interface 2304 by applying the ^abstract factory" 
and „singleton" design patterns as described in [Gam] . 
The ^abstract factory" is defined by the SipRegistrar- 
Factory interface 2312. The SipRegistrar class 2306 is 
designed to use a default implementation by using the 
deflmpl class attribute holding the fully qualified 
class name of the default implementation. Custom imple- 
mentations of the aforementioned SipRegistrarType inter- 
face 2304 can be created by providing specific factory 
classes implementing the aforementioned SipRegistrarFac- 
tory interface 2312. The SipRegistrar class 2306 pro- 
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vides a class method called setRegistrarFactory ( ) , which 
stores a singleton instance of the given custom factory. 

The org: : mind: : sip: : sipApi : .'management sub-package (cf. Fig. 
24) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c applied to the management entity 
102 for configuring and controlling the Service Provider. It 
consists of three major parts: 

1. Interfaces that Service Users shall implement for inter- 
cepting the Indication (Ind) and Confirmation (Cfm) 
primitives generated by the Service Provider: 

SipManagementListener . 

2. Classes bundling parameters for specific primitives 
(currently only the SipConf igurationReq class 2406 for 
the Configuration Request (Req) primitive) . Instances of 
these classes are passed as parameters of the given 
primitives to the modules implementing the primitives. 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 

3. An interface specifying the API that the Service Pro- 
vider shall support for being compatible with the SIP UA 
Generic API 101c. The SipManager interface 2404 speci- 
fies the set of Request (Req) and Response (Rsp) primi- 
tives that the underlying SIP UA implementation shall 
support for being compatible with the SIP UA Generic API 
101c. 



WO 2004/039031 



PCT/EP2003/011439 



The org: : mind: : sip: : sipApi: : time sub-package (cf. Fig.. 25) 
contains interfaces and classes specifying the part of the 
SIP UA Generic API 101c that allow Service Users manipulating 
the SIP Expires header field. It consists of two major parts: 

1. Interfaces and classes specifying the API that the 
Service Provider shall support for being compatible 
with the SIP UA Generic API 101c. The SipExpiresType 
interface 2502 specifies the set of SIP Expires header 
field manipulation operations that the underlying SIP 
UA 110 implementation shall support for being compati- 
ble with the SIP UA Generic API 101c. The SipExpires 
class 2506 wraps any given implementation of the afore- 
mentioned SipExpiresType interface 2502 by applying the 
^abstract factory" and „singleton" design patterns as 
described in [Gam] . The ^abstract factory" is defined 
by the SipExpires Factory interface 2508. The SipExpires 
class 2506 is designed to use a default implementation 
by using the deflmpl class attribute holding the fully 
qualified class name of the default implementation. 
Custom implementations of the aforementioned SipEx- 
piresType interface 2502 can be created by providing 
specific factory classes implementing the aforemen- 
tioned SipExpiresFactory interface 2508. The SipExpires 
class 2506 provides a class method called setSipEx- 
piresFactory () , which stores a singleton instance of 
the given custom factory. 

2. The SipParseException class 2504 represents the excep- 
tion thrown by the Service Provider whenever the pars- 
ing of the SIP Expires header field fails, due to mal- 
formed syntax. 
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In the following subsection, the procedures enabled by the 
SIP UA Generic API 101c shall be described by using a set of 
UML Message Sequence Charts (MSCs) . 

Fig. 26 shows how the Service Provider 110 is configured, and 
how a Service User of the IF3 101c creates and binds as Serv- 
ice User its client and server sub-units with the Service 
Provider 110. Fig. 27 shows how a SIP session can be estab- 
lished through the SIP UA Generic API 101c according to the 
procedures described in [Rosl] . 

This procedure starts with a connectionReq primitive invoked 
by a peer acting as calling party (or initiator) , triggers a 
message exchange, which terminates only when the peer acting 
as called party (or responder) after having initially re- 
ceived a connectionlnd primitive notifying the initiator' s 
invitation to establish a SIP session, eventually accepts 
such invitation (after a number of negotiation and signaling 
steps), and replies with a connectionRsp primitive. 

The responder generates SIP-provisional responses through the 
connectionStatusReq primitive invocations, which map at ini- 
tiator's side to connect ionStatusInd primitive invocations. 
The initiator acknowledges provisional responses with the 
PRACK method, by using the ProvisionalAckReq/Cfm primitive, 
which corresponds at responder' s side to ProvisionalAck- 
Ind/Rsp primitive, respectively. 

This procedure ends with the initiator receiving a connec- 
tionCfm primitive and the responder receiving a connection- 
Statuslnd primitive. The latter is due to the SIP three-way 
acknowledgment scheme described in [Rosl] . 

Two procedures in this MSC are assumed to be executed auto- 
matically by the Service Provider: The generation of the ,,100 
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Trying" provisional response at responder's side, and the 
generation of the final ACK signal at initiator's side. The 
latter can, however, be forced by the Service User itself via 
the connectionStatusRsp primitive, but this means that the 
5 Service User must accordingly be configured not to generate 
the ACK signal automatically. 

Final SIP responses indicating other reasons than success are 
generated either automatically by the Service Provider or ex- 
10 plicitly by the responder f s Service User via the connection- 
StatusReq primitive. These SIP responses are notified to the 
initiator's Service User via the connectionStatusInd primi- 
tive . 

15 Fig. 2 8 shows how the OPTIONS method is handled via the op- 

tionsReq) Ind)Rsp| Cfm primitives. Fig. 29 shows how a SIP ses- 
sion can be released via the disconnectionReql IndlRsp | Cfm 
primitives. The MSC shows the case of BYE, but the same pro- 
cedure invoked during a connection establishment generates a 

20 CANCEL . 

In the following subsection, the Finite State Machine 106 
(FSM) applied to the E2ENP UA 128 shall briefly be described. 

25 The core of the E2ENP UA 128 is composed of a Finite State 
Machine 106 (FSM) , which coordinates the overall functional- 
ity and implements a part of the aforementioned interfaces. 
More specifically, the FSM 10 6 implements the Service User 
part of the IF3, IF4 and IF5, and the Service Provider part 

30 of the IF1 and IF2. Furthermore, the E2ENP UA FSM 106 makes 
use of the Cache 104 described above. 

The FSM 106 is designed hierarchically as a StateChart. In 
the Root State (cf. Fig. 30), the FSM 106 handles session- 
35 terminating events, either associated with local or remote 
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users' decisions. Furthermore, the Root State handles pre- 
negotiation, lease renewal, negotiation as Offerer/Answerer, 
re-negotiation, and session release processes. It should be 
noted that the term ^negotiation" process is used for indi- 
5 eating a multimedia session establishment, intertwined with 
resource reservation coordination and QoS negotiation, as de- 
scribed in [ReqSpec] . 

The role of the Offerer is taken by the peer who is initiat- 
10 ing a session establishment with QoS negotiation and resource 
reservation, but also by the peer who decides to initiate a 
re-negotiation. The role of the Answerer is always taken by 
the peer who is responding to an invitation to carry out a 
session establishment process with QoS negotiation and re- 
15 source reservation, but also by the peer who decides to re- 
spond to an invitation to carry out a re-negotiation. This 
means that a peer initially acting the Offerer role can later 
take either the Offerer or the Answerer role during a re- 
negotiation. And vice versa, a peer initially acting the An- 
20 swerer role can later take either the Offerer or the Answerer 
role during a re-negotiation. 

For the sake of simplicity, Fig. 30 does not detail the han- 
dling of primitives associated with IF1 (Management API) ; 
25 neither the internal interfaces with the FSM factory 106 nor 
the Cache 104 are taken into account. 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 30. 

30 

Lower-level details of the negotiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 106, respectively 
the NegOfferer sub-state (cf . Fig. 31) and the NegAnswerer 
sub-state (cf . Fig. 32) . 

35 
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The NegOfferer sub-state contains a nested FSM 106 capturing 
the logic handling the negotiation process, as seen from the 
Offerer perspective. The NegAnswerer sub-state contains a 
nested FSM 10 6 capturing the logic handling the negotiation 
process, as seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
the combined reservation of local, peer, and network re- 
sources as described in [ReqSpec] , the FSMs 106 nested in the 
NegOfferer sub-state and in the NegAnswerer sub-state use the 
system-wide „_ResvMtx" FSM 106 for accessing the reservation 
phase on a mutually exclusive basis, with respect to other 
instances of the E2ENP UA FSM 106. The „_ResvMtx" FSM 106 in- 
teracts with various instances of the E2ENP UA FSMs 10 6 via 
atomic local methods invocation (e.g. via any specific system 
call provided by the underlying Operating System) . 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 31. 

Lower-level details of the re-negbtiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 106, respectively 
the ReNegOfferer sub-state (cf . Fig. 33) and the ReNegAn- 
swerer sub-state (cf . Fig. 34) . 

- The ReNegOfferer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Offerer perspective. 

- The ReNegAnswerer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
the combined reservation of local, peer, and network re- 
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sources as described in [ReqSpec] , the FSMs 106 nested in the 
ReNegOfferer sub-state and in the ReNegAnswerer sub-state use 
the system-wide „_ResvMtx x> FSM 106 for accessing the reserva- 
tion phase on a mutually exclusive basis, with respect to 
5 other instances of the E2ENP UA FSM 106. The „_ResvMtx" FSM 
106 interacts with various instances of the E2ENP UA FSMs 106 
via atomic local methods invocation (e.g. via any specific 
system call provided by the underlying Operating System) . 

10 • The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 33. 

This mechanism enforces a transaction-like processing of the 
resource reservation phase by enforcing various concurrent 

15 instances of the E2ENP UA Service Users to mutually exclu- 
sively access such a phase, as described in [ReqSpec] . In 
other words, the resource reservation mutex allows defining 
the phase between local admission control and final network 
resource reservation as a critical section. Combined with the 

20 contention resolution policy, this mechanism also guarantees 
that no deadlock situation as- described in [ReqSpec] might 
affect the E2ENP whatsoever. 

Concurrent E2ENP UA Service User instances try to seize the 
25 mutex via suspensive method calls. The Service User instance 
owning the mutex releases it via the signal call event. 

The „JResvMtx" is associated with a priority queue for allow- 
ing multiple requests to seize the mutex in a coordinated 
30 manner, based on their priority (cf . Fig. 35) . 

Any request is served immediately if the mutex is unlocked; 
otherwise, the request is queued. Requests with high priority 
are queued in front of requests with low priority. Requests 
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with the same priority are queued in a „First-In-First-Out w 
(FIFO) order. 

All requests to acquire the mutex are limited in time. Upon 
expiration of such a (configurable) time, the given E2ENP UA 
Service User instance pending on the mutex is resumed with a 
return value indicating failure. 

This design choice allows detecting (and thus preventing) 
starvation of concurrent E2ENP UA Service User instances sus- 
pended on the mutex, which occurs when the Service User in- 
stance owning the mutex is misbehaving (or maybe blocked) . 
This is of most importance, especially in case the ill- 
behaved Service User instance are suspended on some other ap- 
plication-specific mutex, semaphore or lock, eventually 
seized by one of the Service User instances queued on the 
„_ResvMtx": in such an unfortunate situation, a dead lock 
would in fact inevitably occur. 

When the timer associated with each blocked request expires, 
the priority of that request (specified in the parameter list 
of respectively the bookNegotiationReq or bookRenegotiation- 
Req primitives, cf . Tab. 1) should be higher than the prior- 
ity of the one for which the mutex was granted, the mutex 
would throw a signal event, congestionlnd, to the instance of 
the FSM 106 UA associated with the Service User instance own- 
ing the mutex. This event is caught by the E2ENP UA FSM 106 
Root state and mapped to a failurelnd primitive sent to the 
Service User instance owning the mutex. 

According to application-specific policies, such Service User 
instance might react on such event by rolling-back the cur- 
rent status of its activities and starting a release opera- 
tion, which in turn would force the release of the mutex, as 
indicated in Fig. 30. Should however such Service User in- 
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stance act differently (either based on application-specific 
policies or because being blocked or just misbehaving) , the 
other instances would nevertheless be able to detect the pro- 
longed delay on acquiring the mutex (after a configured num- 
ber of failed attempts to invoke the get method success- 
fully) , thanks to the bookNegotiationCfm (or bookRenegotia- 
tionCfm in the re-negotiation case) primitives indicating a 
failure case (see Figs. 31 and 33, respectively). In such 
cases, the notified E2ENP UA Service User instances might in- 
voke the mediation of an application-specific arbitration 
unit. To manage all these exceptional cases/dead locks, the 
resetReq primitive can be issued at any time to cancel the 
current given session and release the mutex, if necessary. 

A key issue typically encountered when using mutex entities 
is the so-called priority inversion problem, which occurs 
whenever a task t 3 owning the mutex has a lower priority than 
other tasks T k blocked on the mutex, and more precisely when 
the T-, gets pre-empted by a task T x with a priority greater 
than Tj but less than T k . 

Given the design choice of enforcing loosely coupled inter- 
faces to both the E2ENP UA Service Users and to the SIP UA 
110, the E2ENP UA 128 containing the „_ResvMtx" implementa- 
tion cannot directly enforce well-known protocols, e.g. the 
Priority Inheritance Protocol or the Priority Ceiling Proto- 
col. This is after all a consequence of designing the E2ENP 
UA 128 as a software component . 

However, if the E2ENP UA FSM 106 is designed to handle a 
thread-pool for processing concurrently multiple instances of 
the FSM 106, the priority inversion problem might be tackled 
at least on this level. In this connection, the enforcement 
of the Priority Inheritance Protocol allows to achieve a good 
performance in handling the aforementioned problem. To this 
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extent, the priority specified in the parameter list of the 
bookNegotiationReq primitive (or bookRenegotiationReq in the 
re-negotiation case, cf . Tab, 1) issued by each E2ENP UA 
Service User instance is assigned as priority of the thread 
serving that FSM 106 instance. The „_ResvMtx" shall therefore 
temporarily raise the priority of the thread associated with 
the FSM 106 instance owning the mutex to the priority of any 
blocked thread if the priority of the latter is greater than 
the one of the former. 

The E2ENP UA 128 thus provides the tools for solving deadlock 
and priority inversion problems: However, this is up to the 
applications 130 or QoS Brokers 130 using such tools to guar- 
antee that those problems will never occur. 

In the following subsection, . the resource reservation coordi- 
nation process shall be described. 

The NegAnswerer (cf. Fig. 32) and ReNegAnswerer (cf. Fig. 34) 
sub-states each contain an instance of the same composite 
state, the WaitForCoordDone sub-state (cf. Fig. 36), whose 
nested FSM 10 6 captures the logic handling the coordination 
of resource reservation signaling required before the An- 
swerer is actually alerted and the Offerer informed corre- 
spondingly thereupon. 

The resource reservation coordination process is based on the 
mechanisms described in [Caml] , with the following differ- 
ences : 

1. The preconditions described in [Caml] can be mapped to 
the E2ENP „qosdef x% section and its corresponding nego- 
tiation process described in [ReqSpec] . 

2. The E2ENP prescribes the synchronization of the reserva- 
tion processes between peers (the „confirm M tag in 
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[CamlJ) as always mandatory due to the ^Economy Princi- 
ple": This means that the end-to-end signaling of the 
„confirm" tag (or anything equivalent) is unnecessary 
and thus shall not be supported by any E2ENP implementa- 
tion. 

3. In case of no network resource reservation carried out 
by the Offerer, the Answerer shall determine this case 
by examining the preconditions sent by the Offerer, and 
correspondingly mark the state RemoteTokenAchieved as 
active in Fig. 3 6, so that the Answerer will be able to 
transparently deal with resource reservation coordina- 
tion. 

Impact on SIP implementation (e.g. the introduction of the 
status response and the new value preconditions" for the 
„Supported" header field of the OPTIONS method) are left for 
further study. 

An important aspect is that the E2ENP described in [ReqSpec] 
explicitly claims that the Economy Principle is always re- 
quired, including the concept described in [Caml] of allowing 
both end-to-end and segmented reservations. In the latter 
case, enforcing the Economy Principle might not always be de- 
sirable. There might in fact be situations where reservation 
can be well done locally on beforehand with no cost and/or 
major impact on session establishment. For instance, some us- 
ers might be attached to an intranet or wireless LAN, where 
network resource reservation might be free and starving other 
users might flexibly be handled. Therefore, the original 
E2ENP shall accommodate this case and rely on the applicabil- 
ity of the Economy Principle to allow the aforementioned 
case. 

It should be noted that the E2ENP does not imply that a di- 
rect interface to reservation entities is available: It is up 
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to the applications 130 or QoS Broker 130 to access those en- 
tities. If the latter wishes to execute a „pre-reservation" 
of network resources, it might do that, but the E2ENP signal- 
ing would still give the right timing to the applications 130 
5 or QoS Broker 130, thereby informing it when the reservations 
at- all sides have been accomplished according to the Economy 
Principle, e.g. which signal has reached the level of the de- 
sired QoS (even though best effort communications might well 
have been started on beforehand, if specified by the applica- 
10 tions 130 or QoS Broker 130, respectively) . 

For the sake of simplicity, the model depicted in Figs. 30 to 
36 only partially details' the handling of unexpected events 
and error cases. Tab. 18 completes the description of said 
15 model by indicating the behavior expected in case any of such 
events or errors occur. 

A set of timers is defined to avoid that the E2ENP UA FSM 106 
gets stuck in a state waiting for an event from the Service 

20 User and/or the SIP UA 110. The treatment of timers for han- 
dling primitives across the E2ENP UA API 101b (T1-T22) does 
not prescribe the E2ENP UA FSM 106 taking autonomously cor- 
rective actions, except for a few cases (missing negotiation- 
Req in Root .NegOf f erer . WaitNegReq and renegotiationReq in 

25 Root.ReNegOfferer . WaitReNegReq) . The E2ENP UA FSM 106 simply 
notifies the misbehaving Service User about the detected 
problem via the failurelnd primitive upon which the Service 
User is supposed to clean up and send a releaseReq primitive 
to the E2ENP UA FSM 106. However, if this counteraction does 

30 not succeed, e.g. owing to massive problems at the Service 
User side, the E2ENP UA FSM 10 6 would detect this situation 
upon expiration of yet another timer: in this case, the E2ENP 
UA FSM 106 finally takes the decision to release the SIP con- 
nection and the overall E2ENP session. To manage all these 

35 exceptional cases/dead locks, the resetReq primitive can be 
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issued at any time to cancel the current given session and 
release the mutex, if necessary. 

However, the composite states Root .ReNegOf ferer, Root.Neg- 
Answerer, Root .ReNegOf ferer, Root .ReNegAnswerer may detect a 
later arrival of the missed primitive (eventually triggered 
by the invocation of the failurelnd primitive) by using each 
an History state (cf. Figs. 31, 32, 33, and 34). With this 
solution, the late primitive arrival would be caught in the 
right original state and processed correctly. This means that 
whenever the aforementioned timers expire, the aforementioned 
composite states shall each take care of updating the history 
to point to the state where the timer expired. 

Should a SIP primitive fail, specific timers (T101-T106) 
would detect the failure at the Root .ReNegOf ferer, Root.Neg- 
Answerer, Root . ReNegOf ferer, Root .ReNegAnswerer composite 
states: In these cases, the same procedure as described above 
(based on the failurelnd primitive) shall be enforced. 

For the interface, similar approaches to the potential prob- 
lem of primitive failure have to be pursued by means of the 
management entity 102, which is however not detailed in this 
section. 

For properly implementing the E2ENP concept, the dual seizure 
event (peers simultaneously initiating a negotiation session 
with each other) shall be properly detected and handled in 
order to allow that consistency is guaranteed and that any 
correlation between outgoing and incoming invitations is en- 
forced. 



The former issue can be addressed by using a mutex for regu- 
lating the access to the Economy Principle phase on a system- 
wide basis (the „__ResvMtx" described in the sections above) . 
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For enforcing any correlation, some additional support is re- 
quired instead. Two possible approaches are envisioned: 

a. to use the push-pull model for allowing both Offerer and 
5 Answerer having a chance to send an offer to the peer, 

thus avoiding the possibility of simultaneously generating 
two negotiations in both directions for the same session; 

b. to treat the attempt of handling negotiations simultane- 
10 ously in both direction as a double seizure, which re- 
quires a contention resolution policy to be enforced (e.g. 
wait on a random timer on both sides, and then retry) . 
But this would mean that both peers should use the same 
external representation of the session ID in order to be 

15 able to detect a double seizure. Otherwise, each of the 

two UAs would treat the outgoing and incoming negotiations 
as independent sessions. This would be similar to the case 
peer A invited peer B to e.g. a videoconf erence, while 
peer B would invite peer A to another videoconf erence, 

20 whereas the videoconf erence could actually be the same. 

The way E2ENP defines the external representation of the 
session ID described in [ReqSpec] allows the two peers 
creating only distinct IDs. Therefore, the E2ENP-speci- 
fication per se does not allow detecting double seizures 

25 at all. 

A reasonable solution to this issue is to enforce the push- 
pull model (first approach) as much as possible and to in- 
clude in the re-negotiation phase the possibility to allow 
30 the Answerer to send an offer to the Offerer at a later time 
(i.e. after the first negotiation has been entirely com- 
pleted) . 

This means that the E2ENP shall allow the Offerer and/or any 
35 Answerer to negotiate with the other Answerers and/or the Of- 
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ferer upgraded or new information for establishing QoS-aware 
multimedia sessions. This means that re-negotiations can be 
subdivided in two classes: 

• planned re-negotiations as described originally in 
[ReqSpec] , 

• unplanned re-negotiations, which are used for negotiat- 
ing upgraded or new information during the lifetime of a 
session. 

An explicit Boolean parameter in the pre-negotiation primi- 
tive indicates which of the two classes the given primitive 
should be used for. Of course, the semantics could be in- 
ferred from the information passed, which would be different 
in the two cases, but the Boolean parameter is a good trade- 
off between having this distinction, which has explicitly 
been made for improving performance, and the need to keep the 
E2ENP UA API 101b and FSM 106 simple by avoiding additional 
primitives . 

However, applying the aforementioned solution might not suf- 
fice in the general case since a non-E2ENP compliant SIP UA 
110 might interfere with E2ENP compliant peers, or one of the 
participants might try to invite some of the other partici- 
pants to a parallel multimedia session and use the E2ENP to 
accomplish this. 

SIP loosely tackles the dual seizure problem by suggesting a 
contention resolution policy (indicated as a „MAY" require- 
ment in [Rosl]), whereby peers abort the invitation by reply- 
ing with an Internal Server Error response, carrying a Retry- 
After SIP header field set-to the time after which the remote 
peer should retry. 
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The dual seizure detection is accomplished by matching all 
messages between each given couple of users, via the To- and 
From-SIP header fields. This means if a first user is using 
UA A and sends an INVITE to a second user on UA B, and vice 
5 versa, both users can detect the dual seizure by using the 
couple (To, From) as a unique identifier for correlating the 
two INVITES. 

But this is not exactly the way E2ENP identifies sessions. If 
10 users are engaged in two independent videoconf erences, the 
E2ENP can actually distinguish such cases by using the ses- 
sion ID described in [ReqSpec] . In any case, the biggest is- 
sue is what -would the SIP UA 110 do in such a case, given 
that the aforementioned SIP requirement is a MAY requirement 
15 and thus not necessarily supported by all SIP implementa- 
tions . 

One has to assume that the aforementioned policy may be im- 
plemented: Thereby, the E2ENP UA 128 would not notice the 
20 dual seizure, except for an indication of an unsuccessful ne- 
gotiation or re-negotiation phase. But one could also get 
into dual seizure troubles if the contention resolution pol- 
icy is not supported by the underlying SIP UA 110 implementa- 
tion. 

25 

To tackle the latter case, the Cache 104 should store for 
each of its entries also the (E2ENPFromAddress, E2ENPTo- 
Address) couple associated with the outgoing INVITE and use 
this information for correlating an incoming INVITE with a 

30 pending outgoing INVITE registered in the Cache 104, thus de- 
tecting the double seizure case: This would then trigger a 
contention resolution policy. This means that every incoming 
INVITE received after sending an INVITE should be checked by 
searching the Cache 104 with the aid of a secondary key, us- 

35 ing the (From, To) couple. Although this is an extra effort, 
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it is only limited to the specific case of receiving an 
INVITE after having sent one. 

As an alternative to the contention resolution policy sug- 
gested by [Rosl], which is eventually implemented by the un- 
derlying SIP UA 110, the E2ENP UA 128 shall support a more 
general policy, which is also applicable to complex scenarios 
like one-to-many or many-to-many described in [ReqSpec] . 

Whenever initiating a negotiation or pre-negotiation phase, 
the E2ENP UA 128 should not only include the session ID de- 
scribed in [ReqSpec] in the offer sent within the INVITE but 
also a hash thereof which takes the IP address of the comput- 
ing unit where the E2ENP UA 12 8 is active into account and a 
time stamp. This hash might also be signed digitally in order 
to improve security aspects [ReqSpec] . The hash will be used 
as a substitute for the session ID in any subsequent SIP mes- 
sage. Should a dual seizure occur, the E2ENP would detect it 
by using the aforementioned (From, To) couple. Thereby, said 
contention resolution policy would be applied as follows: 

♦ If the two peers are not already involved in multimedia 
sessions (which means no entry in the Cache 104 for a 
given local peer) , each peer would compare the hash it 
generated with the one received from the peer. The peer 
with the biggest value is automatically chosen as Offerer 
and thus proceeds with the pre-negotiation or negotiation 
phase as such, whereas the other peer, the „loser", auto- 
matically moves to the Answerer mode, according to the 
following MSC: 
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Application (130) E2ENP UA (128) 

negotiationReq > 

< abortlnd 

< negotiationlnd 

negotiationRsp > 



♦ If the two peers are already involved in multimedia ses- 
sions (which means an entry in the Cache 104 for the given 
(From, To) couple), the „bully" process described in the 
previous point could be applied as well. The peer whose 
request is rejected could apply an unplanned re-negotia- 
tion after the winner of the „bully" process has completed 
its negotiation. An example for this case is the simulta- 
neous detection and re-negotiation reaction of the in- 
volved peers to a QoS violation. 

♦ Since the generated session ID contains also a randomly 
generated number (together with the IP, port, etc. infor- 
mation) for the identification, it is not to be expected 
that some of the peers would always be ^winners" and some 
always „losers w . 

Finally, the aforementioned contention resolution process 
also applies to the case of a negotiation procedure colliding 
with a pre-negotiation procedure or even a lease-renewed pro- 
cedure as well as for the collision of a pre-negotiation pro- 
cedure with a lease-renewed procedure. 

The model described in the previous subsections represents 
the static definition of the E2ENP UA FSM 10 6. At runtime, 
the E2ENP UA -128 shall associate a specific E2ENP session 
with an object representing it. This object - the Session - 
shall contain any information related with the given E2ENP 



WO 2004/039031 



PCT7EP2003/011439 



instance: most notably, a pointer to the current state and 
the instance of all the condition variables defined in the 
model above. 

A thread of execution shall dynamically be associated with 
each of these Session objects: either created on demand, or - 
better - picked up front a thread-pool (potentially with lazy 
initialization) . 

♦ This version of the E2ENP is based on the SIP protocol 
specification described in [Rosl] . If at later time an- 
other session level protocol or a more generic approach is 
chosen, the FSM 10 6 should be reworked in order to mask 
the corresponding changes from applications 130 or QoS 
Brokers 130, thanks to the E2ENP UA API 101b abstraction. 
This means that the interaction of the FSM 106 with the 
E2ENP UA API 101b Service User is a design-invariant. 

♦ The use of the SIP MESSAGE method is tentatively indicated 
in Fig, 30. Alternatively, the SIP OPTIONS method could be 
used. In the scope of the underlying invention, only the 
latter is exposed by the SIP UA Generic API 101c since the 
use of the former for implementing the FSM 106 model de- 
scribed below is still being investigated. 

♦ In order to avoid that entities interfacing with the E2ENP 
UA 128 (e.g. the E2ENP UA 128 Service Users, the SIP UA 
110, and E2ENP management entities 102) directly invoke 
E2ENP UA 128 incoming primitives in response to E2ENP UA 
128 outgoing primitives before the E2ENP UA 128 has ever 
had a chance to reach a stable state configuration, the 
E2ENP UA 128 is by design always loosely coupled with the 
aforementioned external entities. Another reason for this 
design choice is the possibility that otherwise there 
would be a non-null probability that the entities inter- 
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facing with the E2ENP UA 128 might block indefinitely a 
E2ENP UA thread. 

♦ This means that the E2ENP UA 128 shall enforce one incom- 
ing message queue for the whole E2ENP UA FSM 106 as well 
as an outgoing message queue for each of the interfaces 
IF1, IF2, and IF3. The reason for the latter queues is due 
to the fact that the E2ENP UA 128 , which is a software 
component, can not make any assumption on the way applica- 
tions 130 would handle primitives thrown by the UA. 

This approach is not necessary for 1F4 and IF5 since the 
Parser 112 and the Factory 114 are designed as thread- 
safe, re-entrant libraries accessed by the E2ENP UA FSM 
106 via synchronous interfaces. 

♦ Concurrent instances of the E2ENP UA FSM 106 are- handled 
with the aid of a thread-pool. 

The E2ENP UA FSM 10 6 depends on the following compo- 
nents : 

♦ the E2ENP UA API 101b, exposing the E2ENP functionality as 
implemented by the FSM 10 6, 

♦ the Parser API lOld, used for accessing services dealing 
with the parsing of session descriptions contained in re- 
ceived SIP messages, 

♦ the Factory API lOle, used for accessing services dealing 
with the creation of session descriptions to be inserted 
in outgoing SIP messages, 

♦ the SIP UA Generic API 101c, used for accessing SIP serv- 
ices, 
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♦ the E2ENP Management API 101a, used for accessing services 
dealing with the overall E2ENP UA 128 management function- 
ality, and 

♦ the Cache 104, used for storing and correlating identifi- 
5 ers of a given session. 

The E2ENP UA FSM model is described in Figs . 30, 31, 32, 34, 
and 36 in terms of UML State Charts and can be implemented by 
using various well-known design patterns. In any case, as in- 

10 dicated in Fig. 1, the FSMs 10 6 are associated at runtime 

with instances of the applied framework or design pattern to 
implement the model. Each instance is associated with a spe- 
cific SIP phase [ReqSpec] , i.e. pre-negotiation, lease re- 
newal, or negotiation. Re-negotiations run on the same in- 

15 stance as the underlying session established with the corre- 
sponding negotiation. 

In order to handle the life cycle of an FSM 106 instance 
(creation, activation, deactivation, and destruction) , an FSM 

20 instance factory 106 (see Fig. 1) is envisioned. This should 
be a singleton object creating instances of the FSM 106 ei- 
ther upon invocation of specific E2ENP UA API 101b primitives 
(negotiationReq, prenegotiationReq, renewLeaseReq) or upon 
invocation of specific SIP UA Generic API 101c primitives 

25 ( connect ionlnd, optionslnd, messagelnd) . 

Fig. 37 depicts the MSC for a simple pre-negotiation sce- 
nario, wherein the correlation between the E2ENP UA API 101b 
and the SIP UA Generic API 101c via the E2ENP UA FSM 106 is 
30 highlighted. 

Fig. 38 depicts the MSC for a simple session establishment 
scenario, wherein the correlation between the E2ENP UA API 
101b and the SIP UA Generic API 101c via the E2ENP UA FSM 106 
35 is highlighted. In the presented scenario, the confirmation 
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of resource reservation completion from the Offerer side ar- 
rives before the same happens at Answerer side. Likewise, it 
is assumed that the resource reservation process succeeds in 
reserving exactly the amount "of the originally requested re- 
source . 

In the following subsection, the E2ENP UA factory 108 shall 
briefly be described. 

The E2ENP UA factory 108 is a management functionality mod- 
eled according to the ^abstract factory" design pattern de- 
scribed in [Gam] for instantiating a specific E2ENP UA 128 
implementation using an implementation-independent interface 

This entity handles the instantiation of all the classes de- 
scribed in the previous sections required to create an in- 
stance of the E2ENP UA 128. More specifically, the E2ENP UA 
factory 108 creates the following entities: 

♦ an E2ENP UA FSM factory, which in turn creates the E2ENP 
UA FSM static structure, 

♦ the FactoryFactory 120, which in turn creates the E2ENP 
Factory 114, 

♦ the ParserFactory 118, which, in turn creates the E2ENP 
Parser 112, and 

♦ the Cache 104. 

Thereby, said E2ENP UA factory 108 depends on the following 
components : 

♦ the application 130 and/or middleware 130, which may di- 
rectly call the E2ENP UA factory 108, alternatively a man 
agement entity 102. 



WO 2004/039031 



PCT/EP2003/011439 



♦ the E2ENP UA FSM 10 6, whose factory is created by the 
given concrete E2ENP UA factory implementation. 

♦ the Factory 114 and Parser 112, whose factories are cre- 
ated by the given concrete E2ENP UA factory implementa- 
tion. 

♦ the Cache 104, which is created by. the given concrete 
E2E1STP UA factory implementation. 

The E2ENP UA factory 108 has been designed by using the ob- 
ject-oriented paradigm. Thus, it is hereby described by using 
the Unified Modeling Language (UML) . 

In the following, the E2ENP object configuration parameters 
shall briefly be summarized. 

The E2ENP UA 128 and its sub-components (FSM 106, Parser 112, 
Factory 114, Cache 104) are configurable elements. The ini- 
tial configuration should consider the specific features of 
the peer using the E2ENP UA 12 8. 

The E2ENP UA 128 should be initialized with the following pa- 
rameters : 

♦ The E2ENP UA FSMs 106 are initiated with specific time- 
outs for the crucial states, where prompt decisions about 
the performance should be taken. The length of the time- 
outs depends on the specific underlying protocol of the 
E2ENP UA 128 and on the performance features of the re- 
spective peer. The time-outs of the different devices and 
networks may vary with a certain extent. The implementers 
should consider these variations by defining the time- 
outs . 

♦ The Cache 104 does not need any configuration parameters 
and is initiated by the E2ENP UA 128. 
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♦ The Parser 112 and the Factory 114 are respectively con- 
figured with the used underlying protocol type and their 
respective class name. They are initiated by means of the 
E2ENP UA 128. 

The configuration of the E2ENP UA 128 and its respective com- 
ponents can be performed either manually with the aid of a 
Graphical User Interface (GUI) or can be preset with configu- 
ration parameters read from a configuration file. 

Concerning the E2ENP UA FSM 10 6, the following parameters are 
configurable : 

♦ Thread-pool configuration parameters: 

* Maximum number of threads in the E2ENP thread-pool. 

* Selector indicating whether the pool should have a lazy 
initialization (i.e. threads are created only when re- 
quired) . 

• Selector indicating whether thread-pool optimization 
is required (only when lazy initialization is en- 
forced) . For optimization reasons, the pool might be 
reconfigured at runtime based on the actual pool us- 
age . 

=> Thread-pool optimization timer: Upon expiration of 
such timer, the optimization process should be ap- 
plied (i.e. unused threads released) . 

♦ Timers (cf . Tab. 19) . 

♦ Mutex: 
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* Timer for detecting potential indefinite lock of the 
mutex, eventually with the aid of a low-priority in- 
stance of the FSM 106 (cf . TM in Tab. 19) . 

5 * The number of attempts to get said mutex is limited by a 

maximum number (Max-Attempts) . 

The SIP UA implementation 110 shall allow configuring at 
least the following parameters : 

10 

♦ Underlying Session Protocol: This is the protocol used by 
E2ENP for carrying its meta-messages (SIP, RMI, socket) . 
In future specifications of E2ENP, other session-layer 
protocols could be used (e.g. H323) . 

15 

♦ Underlying Transport Protocol: The type of transport pro- 
tocol to be used by SIP. In future specifications, this 
parameter might become a configuration parameter of the 
SIP UA 110 itself. 

20 

The following subsection provides information about the deci- 
sion to make communication between the E2ENP UA 128 and the 
Parser 112 respectively the Factory 114 synchronous. In this 
connection, the E2ENP UA 128 shall support multiple concur- 
25 rent instances of the E2ENP UA FSM 106. In order to avoid an 
unbounded usage of OS resources, the E2ENP UA 128 shall en-- 
force a thread pool . 

Communication between the E2ENP UA 128 and the Parser 112 re- 
30 spectively Factory 114 could also be asynchronous, e.g. im- 
plemented by an active request interface and a passive con- 
firmation interface. This option is not used within the scope 
of the underlying invention because some gain in performance 
and flexibility is opposed by much more complicated state 
35 models for the FSMs 106 of the E2ENP UA 128. 
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One consequence of this decision is that the E2ENP UA 128 
and the Parser 112 (also the Factory 114) communicate syn- 
chronously, thus having to share a common address space, 
which in most circumstances is a reasonable assumption. An- 
other consequence of this decision is that both the Parser- 
Factory and the FactoryFactory have to be designed as thread- 
safe, re-entrant libraries. 

Due to the discussion above, it is decided that communication 
between the E2ENP UA 128 and the Parser 112 as well as the 
Factory 114 is synchronous. 

In conclusion, the main advantageous differences between the 
underlying invention and the state of the art shall be empha- 
sized. Briefly summarized, the main benefits of the proposed 
approach consists in 

- a QoS pre-negotiation with a lease-based management of pre- 
negotiated information, QoS negotiation, and QoS re-nego- 
tiation, and 

- a resource reservation and/or release coordination offered 
by the E2ENP UA 128. 

Moreover, the information to be negotiated (capabilities, ap- 
plication-level QoS Contracts, network-level QoS Contracts, 
stream-level adaptation paths, and stream-group-level adapta- 
tion paths) can be expressed in an interchangeable format in 
such a way that heterogeneous applications 130 and/or middle- 
ware 130 can easily agree on a reference model, which said 
applications 130 and/or said middleware 130 can then use for 
dynamically configuring Finite State Machines 106 (FSMs) in 
order to orchestrate local, peer, and network resources ac- 
cording to the preferences and profiles of the respective 
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user, policies of the respective systems and network provid- 
ers in a coordinated manner among a plurality of heterogene- 
ous applications 130 and middleware 130 used by various 
peers . 

Finally, said E2ENP UA 128 can be used for any session-layer 
protocol and session description language, a plurality of ap- 
plications 130 and different types of middleware 130. 
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Table A: Used Abbreviations 



Abbr . 


Brief Explanation 


ABNF 


Augmented Backus-Naur Form 


API 


Application Programming Interface 


ASCII 


American Standard Code for Information Interchange 


E2ENP 


End-to-End Negotiation Protocol 


FSM 


Finite State Machine 


IF<X> 


Interface <X> 


IP 


Internet Protocol 


IPv6 


IP version 6 


LAN 


Local Area Network 


MIME 


Multi-Purpose Internet Mail Extensions 


MSC 


Message Sequence Chart (UML) 


OS I 


Open Systems Interconnection 


QoS 


Quality of Service 


RMI 


Remote Method Invocation 


RPC 


Remote Procedure Call 


SAP 


Service Access Point 


SDP 


Session Description Protocol 


SDPng 


Session Description Protocol (next generation) 


SIP 


Session Initiation Protocol 


UML 


Unified Modeling Language 


XML 


Extensible Markup Language 
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Table B: Depicted Features and their Corresponding 
Reference Signs 



No. 


Technical Feature 


100 


block diagram showing the applied architecture for the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) according to the underlying invention 


101a 


E2ENP Management API (= interface IF1) between the E2ENP 
UA Factory 108 and the Management Entities 102 


101b 


E2ENP UA API (= interface IF2) between the E2ENP UA 128 
and any application 130 or middleware 13 0 using the 
services offered by said E2ENP UA 128 


101c 


SIP UA Generic API (= interface IF3) between the E2ENP 
UA FSM 106 and the carrier protocol UA 110 (SIP, RMI, 
etc.) 


lOld 


Parser API (= interface IF4) between the E2ENP UA FSM 
106 and the implemented Parser 112 \ 


lOle 


Factory API (= interface IF5) between the E2ENP UA FSM 
106 and the implemented Factory 114 


102 


E2ENP Management Entities of the E2ENP architecture 10 0 


103 


Cache API between the Cache 104 and the E2ENP UA FSM 106 


104 


two -stage Cache of the E2ENP architecture 100, connected 
to the Finite State Machine (FSM) 106 of the E2ENP User 
Agent (UA) 12 8 


106 


Finite State Machine (FSM) applied to the E2ENP User 
Agent: vua; 128 or tne E2ENP architecture 100 


108 


E2ENP UA generation factory of the E2ENP architecture 
100 


108a 


SIP-based E2ENP UA generation factory of the E2ENP ar- 
chitecture 100 


110 


placeholder for the implementation of the carrier proto- 
col (SIP, RMI, etc.) User Agent (UA) , also referred to 
as Service Provider 
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No. 


Technical Feature 


110a 


SIP User Agent (UA) used for the UA implementation 110 
of the carrier protocol within the applied E2ENP archi- 
tecture 100 according to the first implementation exam- 
ple 200 


110b 


Java Remote Method Invocation (RMI) -based User Agent 
(UA) used for the UA implementation 110 of the carrier 
protocol within the applied E2ENP architecture 100 ac- 
cording to the second implementation example 3 00 


110c 


socket -based User Agent (UA) used for the UA implementa- 
tion 110 of the carrier protocol within the applied 
E2ENP architecture 100 according to the third implemen- 
tation example 40 0 


112 


placeholder for the implementation of the applied Parser 


112a 


SDPng Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the 
first implementation example 2 00 


112b 


Dummy Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the sec.r 
ond implementation example 3 00. The Dummy Parser is used 
together with the Java RMI based UA 110b. 


112c 


Dummy Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the 
third implementation example 400. The Dummy Parser is 
used together with the socket based UA 110c. 


114 


placeholder for the implementation of the applied Fac- 
tory 


114a 


SDPng Factory used for the Factory implementation 114 of 
the applied E2ENP architecture 100 according to the 
first implementation example 200 


114b 


Dummy Factory used for the Factory implementation 114 of 
the applied E2ENP architecture 100 according to the sec- 
ond implementation example 3 00. The Dummy Factory is 
used together with the Java RMI based UA 110b. 



WO 2004/039031 



PCT/EP2003/011439 



No. 
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114c 


Dummy Factory used for the Factory implementation 114 of 
the applied E2ENP architecture 100 according to the 
third • implementation example 400. The Dummy Factory is 
used together with the socket based UA 110c. 


116 


Generation factory of the carrier protocol User Agent 
(UA) implementation 


116a 


Java-based SIP agent 110a generation factory for the 
carrier protocol User Agent 110 for SIP according to the 
first implementation example 200 


116b 


RMI agent 110b generation factory for the carrier proto- 
col User Agent 110 for Java RMI according to the second 
implementation example 300 


116c 


Socket -based agent 110c generation factory for the car- 
rier protocol User Agent 110 for socket-based connec- 
tions according to the third implementation example 400 


118 


Generation factory of the applied Parser implementation 
112 


118a 


SDPng Parser 112a generation factory (ParserFactory) of 
the applied Parser 112 according to the first implemen- 
tation example 200 


118b 


Dummy Parser 112b generation factory (ParserFactory) of 
the applied Parser 112 according to the second implemen- 
tation example 3 00 


118c 


Dummy Parser 112c generation factory (ParserFactory) of 
the applied Parser 112 according to the third implemen- 
tation example 40 0 


120 


Generation factory of the applied Factory implementation 
114 


120a 


SDPng Factory 114a generation factory (FactoryFactory) 
of the applied Factory 114 according to the first imple- 
mentation example 200 


120b 


Dummy Factory 114b generation factory (FactoryFactory) 
of the applied Factory 114 according to the second im- 
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No. 


Technical Feature 




plementation example 300 ! 


120c 


Dummy Factory 114c generation factory (FactoryFactory) 
of the applied Factory 114 according to the third imple- 
mentation example 400 j 


122 


Java-based SIP stack (JSIP) applied as a component of 
the said SIP User Agent (UA) 110a 


124a 


Remote Method Invocation (RMI) skeleton of the Java RMI- 
based User Agent (UA) 110b according to the second im- 
plementation example 3 00 


124b 


Remote Method Invocation (RMI) stub of the Java RMI - 
based User Agent (UA) 110b according to the second im- 
plementation example 3 00 


126a 


TX socket of the socket-based User Agent (UA) 110c ac- 
cording to the third implementation example 400 used for 
transmitting strings or objects 


126b 


RX socket of the socket -based User Agent (UA) 110c ac- 
cording to the third implementation example 400 used for' 
receiving strings or objects 


126c 


Adapter of the socket-based User Agent (UA) 110c accord-, 
ing to the third implementation example 400 used for re- 
ceiving and/or transmitting strings or objects using the 
said sockets 126a+b 


128 


combined unit comprising said Cache 104, said E2ENP UA 
FSM 106, and said E2ENP UA Factory 108, in the following 
referred to as E2ENP-based User Agent (E2ENP UA) 


130 


multi- session multimedia application or QoS Broker 
(middleware) using the E2ENP UA API 101b to connect with 
the E2ENP UA 12 8 


200 


first implementation example of the applied architecture 
for the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) according to one embodiment of the un- 
derlying invention using a Java-based SIP Stack (JSIP) 
and SDPng Parser and Factory 
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300 


second implementation example of the applied architec- 
ture for the User Agent (UA) of the End-to-End Negotia- 
tion Protocol (E2ENP) according to one embodiment of the 
underlying invention using Sun's Java Remote Method In- 
vocation (RMI) 


400 


third implementation example of the applied architecture 
for the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) according to one embodiment of the un- 
derlying invention using the socked-based User Datagram 
Protocol (UDP) or Transmission Control Protocol (TCP) 


500 


UML class diagram showing the org: : mind: :e2enp package 


502 


E2ENPUSerAgentListener interface within the 
org: : mind: :e2enp package 


504 


Provider interface within the org :: mind: : e2enp package 


506 


Of f ererListener interface, generalized to said interface 
Listener 502 within the org :: mind: :e2enp package 


508 


AnswererListener interface, generalized to said inter- 
face Listener 502 within the org: : mind: :e2enp package 


510 


ManagerProvider interface 


512 


ManagerListener interface | 


514 


class Conf igurationRequest 


516 


class Par serFac t oryConf igurat i on 


600 


Augmented Backus -Naur Form (ABNF) of the E2ENP address 
as a Universal Resource Identifier (URI) 


700 


first message sequence chart (MSC) showing the pre-nego- 
tiation procedure enabled by the User Agent (UA) 12 8 of 
the End-to-End Negotiation Protocol (E2ENP) 


702 


class Of f ererServiceUser, derived from the class 
E2ENPUserAgentListener , implementing the Listener inter- 
face 502 


704 


class Of f ererServiceProvider, derived from the class 
Provider, which implements the Provider interface 504 


706 


class AnswererServiceProvider, derived from the class 
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No. 


Technical Feature 




Provider, which implements the Provider interface 504 


708 


class AnswererServiceUser, derived from the class 
E2ENPUserAgentListener / implementing the Listener inter- 
face 502 


800 


second message sequence chart (MSC) showing the session 
establishment with a QoS negotiation and resource reser- 
vation coordination enabled by the User Agent (UA) of 
the End-to-End Negotiation Protocol (E2ENP) 


900 


UML class diagram showing the org: : mind: :e2enp: : Cache 
sub-package 


902 


class LevelOneCache representing the first level (LI) of 
the two- stage Cache 104 


904 


class LevelTwoCache representing the second level (L2) 
of the two-stage Cache 104 


906 


class LevelOneEntry encompassing methods for storing and 
loading information to/ from the first level (LI) of said- 
two -stage Cache 104 


908 


class LevelTwoEntry encompassing methods for storing and 
loading information to/ from the second level (L2) of 
said two- stage Cache 104 


1000 


diagram showing the top-level view of an Extensible 
Markup Language (XML) description used for the End- to- 
End Negotiation Protocol (E2ENP) 


1001 


Complex Type definition descType of the SDPng desc ele- 
ment. The illustration also incorporates the E2ENP spe- 
cific changes made by the redefine mechanism. 


1002 


„e2enp: purpose" child element of the „desc u element. 


1003 


„sdpng:def" child element of the „desc" element. 


1004 


„sdpng:cfg" child element of the „desc n element. 


1005 


„sdpng: constraints u child element of the „desc M element. 


1006 


„sdpng:conf u child element of the „desc w element. 


1100 


diagram showing the XML substitution groups used for the 
End-to-End Negotiation Protocol (E2ENP) 
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1101 


Complex Type definition descType of the SDPng desc ele- 
ment. The illustration also incorporates the E2ENP spe- 
cific changes made by the redefine mechanism. 


1102 


„e2enp : purpose" child element of the „desc u element. j 


1103 


„sdpng:def" child element of the „desc u element. 


1104 


„sdpng:cfg u child element of the „desc w element. 


1105 


„sdpng: const raints" child element of the „desc u element. 


1106 


„sdpng : conf * child element of the „desc" element. 


1107 


„sdpng:d u element, head of the substitution group which 
defines the valid child elements of the „sdpng:def u sec- 
tion. 


1108 


„ audio : codec w element, member of the „sdpng:d w substitu- 
tion group. 


1109 


„e2enp : qosdef u element, member of the „sdpng:d" substi- 
tution group. 


1110 


„rtp:pt u element, member of the „sdpng:d" substitution 
group . 


1111 


„rtp : transport w element, member of the „sdpng:d u substi- 
tution group. This element in turn is head of the 
„rtp : transport w substitution group. 


1112 


„rtp:udp u element, member of the „rtp : transport * substi- 
tution group. 


1113 


„ video : codec w element, member of the „sdpng:d" substitu- 
tion group. 


1200 


diagram showing the XML purpose element used for the 
End-to-End Negotiation Protocol (E2ENP) 


1201 


„ purpose" element. Can be used to convey additional in- 
formation about the description following in the proto- 
col data unit (PDU) . 


1202 


„e2enp:use" element. Child of the „purpose" section, can 
be used to indicate referenced sessions . 


1203 


^description" element. Can be used to indicate a de- 
scription PDU. 
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1204 


^mediation" element. Can be used to indicate a mediation 
PDU. 


1205 


„e2enp : session" element 


1206 


„ expires" element 


1300 


diagram showing the XML qosdef element used for the End- 
to-End Negotiation Protocol (E2ENP) 


1300' 


XML qosdef element 


1301 


„audio: codec" element. Describes an audio capability of 
the system. 


1302 


„ video: codec" element. Describes an video capability of - 
the system. 


1303 


„rtp:pt" element. Can be used to specify a desired pay- 
load format for a given capability. 


1304 


„e2enp: policy" element. Can be used to specify the re- 
source management policy to enforce. 


1305 


„e2enp: audio" element. Can be used to describe the QoS 
contracts for audio streams. 


1306 


„e2enp : video" element. Can be used to describe the QoS 
contracts for video streams . 


1307 


„e2enp: control" element. Can be used to describe the QoS 
contracts for control streams. 


1308 


„e2enp:data" element. Can be used to describe the QoS 
contracts for data streams. 


1309 


„rtp:map" element. Can be used to define a mapping be- 
tween an application level QoS Contract and a specific 
RTP payload format. 


1310 


„e2enp : contract" element 


1311 


„ predicate" element 


1312 


„ criterion" element 


1400' 


XML qoscfg element 


1400 


diagram showing the XML qoscfg element used for the End- 
to-End Negotiation Protocol (E2ENP) 


1401 


„e2enp : context" element. Can be used to define associa- 
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tions between data streams and thus to express time syn- 
chronization and/or QoS correlation. Briefly, this ele- 
ment defines high level QoS Contracts. 


1402 


„ e2 enp : adapath w element 


1403 


„ default 1 " element 


1404 


„alt w element 


1405 


„ event " el ement 


1406 


„path" element 


1407 


„ comp * element 


1408 ; 


„ constraints w element 


1409 


„par u element 


1500 


UMIj message sequence chart (MSC) showing the interaction 
between the E2ENP User Agent (UA) 12 8 according to the 
underlying invention and the applied Parser 112 and 
Cache 104 


1700 


UML class diagram showing the general structure of a 
Document Object Model (DOM) tree 


1702 


class DocumentTree, which models the general structure 
of said DOM tree and can therefore be interpreted as the 
document root element 


1704 


class DocumentNode aggregated to said class DocumentTree 
1702, which in turn aggregates between 0 and n children, 
thus recursively describing the tree structure 


1800 


UML class diagram showing a structural overview of the 
Parser implementation 112 using a „ visitor design pat- 
tern" for traversing the DOMTree 18 04 and generating a 
XMLObject 1802 


1802 


class XML Object used within the Parser implementation 
112 


1804 


class DOMTree, which models the general structure of 
said DOM tree and can therefore be interpreted as the 
document root element 


1806 


class DOMNode aggregated to said class DOMTree 1804 
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1808 


generic Parser visitor class pVisitor, which visits be- 
tween 1 and N DOMNode s 


1810a 


first specialized DOMNode of said class DOMNode 1806 


1810n 


N-th specialized DOMNode of said class DOMNode 1806 


1812a 


first specialized Parser visitor class pVisitor 1, which 
is applied to handle the first derived DOMNode 


1812n 


N-th specialized Parser visitor class pVisitor N, which 
is applied to handle the N-th derived DOMNode 


1900 


UML message sequence chart (MSG) showing the interaction 
between the E2ENP User Agent (UA) 12 8 according to the 
underlying invention and the applied Factory 114 and 
Cache 104 


2000 


UML class diagram showing a structural overview of the 
Factory implementation 114 


2002 


generic Factory visitor class fVisitor, which visits be- 
tween 1 and N instances of Ob j ectGraphNode classes 


2004 


class Ob j ectGraphNode used within the Factory implemen- 
tation 114 


2006a 


first specialized Factory visitor class fVisitor 1, 
which is applied to handle the first derived Node 2 008a 
of the class Ob j ectGraphNode 2 004 


2006n 


N-th specialized Factory visitor class fVisitor N, which 
is applied to handle the N-th derived Node 2008n of the 
class Ob j ectGraphNode 2 0 04 


2008a 


first specialized Node (subclass) of the class Ob- 
j ectGraphNode 2 0 04 


2008n 


N-th specialized Node (subclass) of the class Ob- 
j ectGraphNode 2 004 


2100 


UML class diagram showing the org :: mind :: sip :: sipApi 
package 


2102 


class management of the org :: mind: : sip :: sipApi package 


2104 


class userAgent of the org :: mind: : sip :; sipApi package 


2106 


class registrar of the org :: mind: : sip :: sipApi package 
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2107 


class time of the org :: mind: : sip :: sipApi package 


2108 


interface SipListener of the org: : mind: : sip :: sipApi 
package ! 


2110 


interface SipProvider of the org: :mind: :sip: : sipApi 
package 


2112 


class SipExpiresHandling of the org: : mind :: sip :: sipApi 
package j 


2114 


class SipEndUser of the org: : mind :: sip :: sipApi package 


2200 


UML class diagram showing the 

org: :mind: :sip: : sipApi: ruserAgent package ' 


2202 


interface SipUserAgentListener of the 
org: :mind: :sip: : sipApi: :userAgent package 


2204 


interface SipUserAgentServerListener of the 

org: :mind: :sip: : sipApi: :userAgent package, derived from 

the class SipUserAgentListener 22 02 


2206 


interface SipUserAgentClientListener of the 

org::mind: :sip: :sipApi: :userAgent package, derived from 

the class SipUserAgentListener 22 02 


2208 


Class SipConnectionReq of the 

org: :mind: :sip: : sipApi: :userAgent package 


2210 


interface SipUserAgentType of the 

org: :mind: :sip: : sipApi: :userAgent package 


2212 


interface SipUserAgentFactory of the 

org: :mind: :sip: : sipApi: :userAgent package 


2214 


class SipUserAgent of the 

org: :mind: :sip: : sipApi: :userAgent package, derived from 
the class SipUserAgentType 2210 


2214a 


class UAClient of the 

org: : mind: : sip: : sipApi : ruserAgent package, derived from 
the class SipUserAgent 2214 


2214b 


class UAServer of the 

org: :mind: :sip : : sipApi: ruserAgent package, derived from 
the class SipUserAgent 2214 



WO 2004/039031 



PCT/EP2003/011439 



No. 


Technical Feature 


2216 


class SipNegotiationModel of the 

org: :tnind: :sip: : sipApi: ruserAgent package 


2218 


class SipRegistrationReq of the 

org: :mind: :sip: :sipApi: ruserAgent package 


2220 


class SipRegistrationCfm of the 

org: :mind: :sip: rsipApi: :userAgent package 


2300 


UML class diagram showing the 

org: :mind: :sip: :sipApi: : registrar package 


2302 


interface SipRegistrarListener of the 
org: :mind: :sip: : sipApi: : registrar package 


2304 


interface SipRegistrarType of the 

org: :mind: :sip: :sipApi: : registrar package 


2306 


class SipRegistrar of the 

org: : mind: : sip: : sipApi : : registrar package, derived from 
said class Sip- RegistrarType 2304 


2308 


class SipRegistrationlnd of the 

org: :mind: :sip: :sipApi: : registrar package 


2310 


class SipRegistrationRsp of the 

org: :mind: :sip: :sipApir : registrar package 


2312. 


interface SipRegistrarFaetory of the 
org: :mind: :sip: : sipApi : : registrar package 


2400 


UML class diagram showing the i 
org: :mind: :sip: : sipApi: : management package 


2402 


interface SipManagementListener of the 
org : :mind: : sip : : sipApi : :management package 


2404 


interface SipManager of the 

org : : mind : : sip : : sipApi : : management package 


2406 


class SipConf igurationReq of the 

org: :mind: :sip: : sipApi: : management package 


2500 


UML class diagram showing the 

org: :mind: :sip: : sipApi: :time package 


2502 


interface SipExpiresType of the 

org : : mind : : sip : : sipApi : : t ime package 
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2504 


class SipParseException of the 

org: :mind: :sip: :sipApi: :time package 


2506 


class SipExpires of the 

org: :mind: :sip: :sipApi: :time package 


2508 


interface SipExpiresFactory of the 
org: :mind: :sip: :sipApi: :time package 


2600 


UML message sequence chart (MSC) showing the configura- 
tion of the Service Provider and the binding of the 
Service User with said Service Provider 


2700 


UML message sequence chart (MSC) showing the connection 
establishment between the User Agents of a client and a 
server 


2800 


UML message sequence chart (MSC) showing the OPTIONS 
method used for the End-to-End Negotiation Protocol 
(E2ENP) 


2900 


UML message sequence chart (MSC) showing the connection 
release between the User Agents of a client and a server 


3000 


first state transition diagram for a nested Finite State 
Machine (FSM) showing the mut ex- related procedures exe- 
cuted in the root state 


3100 


second state transition diagram for a' nested Finite 
State Machine (FSM) showing the mutex- related procedures 
executed in the NegOfferer sub- state 


3200 


third state transition diagram for a nested Finite State 
Machine (FSM) showing the mutex- related procedures exe- 
cuted in the NegAnswerer sub- state 


3300 


fourth state transition diagram for a nested Finite 
State Machine (FSM) showing the mutex-related procedures 
executed in the ReNegOfferer sub- state 


3400 


fifth state transition diagram for a nested Finite State 
Machine (FSM) showing the mutex-related procedures exe- 
cuted in the ReNegAnswerer sub- state 


3500 


sixth state transition diagram for the JResvMtx Finite 
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State Machine (FSM) for allowing multiple requests to 
seize the mutex in a coordinated manner, based on their 
priority 


3600 


seventh state transition diagram for a nested Finite 
State Machine (FSM) showing the mut ex-related procedures 
executed in the WaitForCoordDone sub- state 


3700 


UML message sequence chart (MSC) showing the pre -nego- 
tiation procedure needed for the correlation of the Ap- 
plication Programming Interface (API) of the E2ENP User 
Agent (UA) and the generic Application Programming In- 
terface (API) of the SIP User Agent (UA) , thereby using 
the above-mentioned Finite State Machine (FSM) of the 
E2ENP User Agent (UA) 


3 702 


class Of fererSIPServiceUser, implementing the interface 
SipUserAgentClientListener 2206 


3704 


class Of f ererSIPServiceProvider, derived from the class 
SipUserAgent 2214 


3706 


class AnswererSIPServiceProvider, derived from the class 
SipUserAgent 2214 


3708 


class AnswererSIPServiceUser, implementing the interface 
SipUserAgentServerListener 22 04 


3800 


UML message sequence chart (MSC) showing the session es- 
tablishment with the QoS negotiation procedure and the 
resource reservation coordination needed for the corre- 
lation of the Application Programming Interface (API) of 
the E2ENP User Agent (UA) and the generic Application 
Programming Interface (API) of the SIP User Agent (UA) , 
thereby using the above-mentioned Finite State Machine 
(FSM) of the E2ENP User Agent (UA) 


3900 


Tab. 1: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the Application Programming Interface (API) applied 
to the User Agent (UA) of the End-to-End Negotiation 
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Protocol (E2ENP) 


4000 


Tab. 2: table showing a list of primitives to be imple- 
mented by the Service User, based on a Java implementa- 
tion of the Application Programming Interface (API) ap- 
plied to the User Agent (UA) of the End-to-End Negotia- 
tion Protocol (E2ENP) 


4100 


Tab. 3: table showing a list of primitives to be imple- 
mented by the Service User acting as an Offerer, based 
on a Java implementation of the Application Programming 
Interface (API) applied to the User Agent (UA) of the 
End-to-End Negotiation Protocol (E2ENP) 


4200 


Tab. 4: table showing a list of primitives to be imple- 
mented by the Service User acting as an Answerer, based 
on a Java implementation of the Application Programming 
Interface (API) applied to the User Agent (UA) of the 
End-to-End Negotiation Protocol (E2ENP) 


4300 


Tab. 5: table showing the methods provided by the Appli- 
cation Programming Interface (API) of the first Cache 
level 


4400 


Tab. 6: table showing the methods provided by the Appli- 
cation Programming Interface (API) of the second Cache 
level 


4500 


Tab. 7: table showing a list of primitives which have to 
be implemented by the Application Programming Interface 
(API) of the Parser 


4600 


Tab. 8: table showing a list of primitives which have to 
be implemented for generating a specific parser instance 


4700 


Tab. 9: table showing a list of primitives which have to 
be implemented by the Application Programming Interface 
(API) of the Factory 


4800 


Tab. 10: table showing a list of primitives which have 
to be implemented for generating a specific factory in- 
stance 
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4900 


Tab. 11: table showing the methods provided by the well- 
known factory- factory class E2ENPContentHandlerFactory 


5000 


Tab. 12: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) 


5100 


Tab. 13: table showing a list of client-side-specific 
primitives implemented by the Service User, based on a 
Java implementation of the generic Application Program- 
ming Interface (API) applied to the User Agent (UA) of 
the End-to-End Negotiation Protocol (E2ENP) 


5200 


Tab. 14: table showing a list of server-side-specific 
primitives implemented by the Service User, based on a 
Java implementation of the generic Application Program- 
ming Interface (API) applied to the User Agent (UA) of 
the End-to-End Negotiation Protocol (E2ENP) 


5300 


Tab. 15: table showing a list of both client-side- and 
server-side-specific primitives implemented by the Serv- 
ice User, based on a Java implementation of the generic 
Application Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) 


5400 


Tab. 16: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) 


5500 


Tab. 17: table showing a list of primitives implemented 
by the Service User, based on a Java implementation of 
the generic Application Programming Interface (API) ap- 
plied to the User Agent (UA) of the End-torEnd Negotia- 
tion Protocol (E2ENP) 
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5600 


Tab. 18: state transition table showing a survey of the 
applied exception events 


5700 


Tab. 19: table showing the applied timers applied to the 
End-to-End Negotiation Protocol (E2ENP) according to the 
underlying invention 



